Skip to content

{ Author Archives }

A kata above

The code kata is a method software craftspeople use to practice their craft. The idea is that you take a problem you understand, like FizzBuzz or Conway’s Life, and build an application that implements it. Then build another one. And another. Pretty soon, you should be quite good at building a thing with well-understood requirements. […]

The Design of the Bazaar

In The Design of Design, Fred Brooks makes an interesting point about ESR’s description of the Bazaar model of Linux (and, by extension, “Open Source”) development. Linux was actually designed in a cathedral. The design was supplied by Unix, where Linux was to be a work-alike replacement for a particular component. There was even a […]

An acceptable tool

An acceptable tool It’s easy to forget that adequacy is, well, adequate. It’s easy to go all-in on making some code structure perfect, when good enough would be good enough.

Beware the IDEs

I recently had the opportunity to talk with a couple of software project managers from IBM. That company is of a kind that I have never worked at, and many of the companies I have worked at are of kinds that these IBMers have not worked at. There was thus plenty of opportunity for us […]

Hiding behind messages

A problem I think about every so often is how to combine the software design practice of hiding implementations behind interfaces with the engineering practice of parallel execution. What are the trade-offs between making parallelism explicit and information hiding? Where are some lines that can be drawn? Why do we need abstractions for this stuff, […]

It depends? It depends.

Sometimes you ask a question which has a small collection of actionable answers: yes or no. You ask someone who should be able to give that yes or no answer, and they go for the third: it depends. Maybe they can’t actually answer your question, but want to sound profound. Maybe they don’t realise that […]

GNU Terry Pratchett

(post-hoc prescript: I admit to being in two minds about sharing this post. Name-dropping can be the ultimate in reflected vanity: I have worth because I knew this worthy person. I title it about them, but we both know it’s about me. I hope this post, containing much as it does about me and my […]

Linus’s Bystanders

For some reason, when Eric S. Raymond wanted to make a point about the “bazaar” model of open source software development, he named it after someone else. Thus we have Linus’s Law: Linus was directly aiming to maximize the number of person-hours thrown at debugging and development, even at the possible cost of instability in […]

Inspired by Swift

Gulliver meets the Oopers Lemuel Gulliver’s world was black. No light, no sound, infinite darkness and solitude. Am I dead?, he asked himself. No, surely not. He opened his eyes. Still, everything remained black. My God, I am dead! Lemuel Gulliver began to panic. Then, slowly, he realised that panicking itself meant life: My heart […]

Fun and games (with rewritten rules) in Objective-C

An object-oriented programming environment is not a set of rules. Programs do not need to be constructed according to the rules supplied by the environment. An object-oriented environment includes tools for constructing new rules, and programs can use these to good effect. Let’s build multiple method inheritance for Objective-C, to see a new set of […]