Talk About Quality

Tom Harris

Not Like Anything You’ve Ever Seen

with 4 comments

Practitioners in other professions may have the problem that the average person doesn’t understand their fields.

We in software development have a different problem. We’re not sure ourselves that we understand our field. How else to explain the fact that we change methods and models every five years, and are fascinated when we realize that something that has worked for years “in the real world” works in software too?

And the reason that we’re not sure? It hinges on the question, “What is software like?”

I’m confident that if software were like something familiar from our growing up, we’d recognize it when we got to it and work much more effectively.


For a start, there’s one thing that most people seem to have forgotten. Software was named that because it’s “soft”. It’s not a machine. That’s “hardware”. It’s not a building. That’s concrete — certainly not soft. (By the way, if software is not a building, forget “software construction”.)

Answers that are not

Knowledgeable people will say that software is a procedure to tell hardware what to do. Or in these days of interactive software, to tell hardware how to behave and respond.

But “procedures” are hardly familiar in daily life. Mostly we live and react with little planning, and no procedures. Saying software is a “procedure” is as good as telling me that an “aperea” is a “cavy”. Go look it up.

So what is software like?

How about a kitchen. The layout, appliances, and supplies are the source code. The food you prepare is the object code. And of course the ravenous teenagers at the table are the end users. They change their minds a lot about the requirements. You have to deliver on time and in quantity. And it had better be good too or they’ll just go out for pizza.

Wait a minute though. We generally don’t go re-purposing our kitchens every few weeks. Yes, we might buy a new kitchen gadget here and there, and there are renovations on the traditional 7-year cycle. But it’s still one cook (could be either parent, but usually one of them says, “this is my kitchen”). And the same clientele.

The Cooperative Kitchen

Imagine an unusual, cooperative kitchen. Maybe in some super-modern tourist hostel. It’s got basic appliances and counter space and cabinets. But every week a few different groups come. A family. A company retreat. A summer camp trip. Their cooks all sharing the kitchen, bringing their own pots and pans, recipes, and food supplies.

They cook in shifts: the camp counselors get from 6:30 AM to 7 AM to cook before their hike. Then the family, who wants to get out and see things, gets it from 7 AM for half an hour. Finally, the catering cook comes in to prepare food for the morning corporate meetings. And remember, all these groups will be back for lunch and dinner, so tools and supplies have to be left out somewhere, ready to be used again.

Coding the Kitchen

Now imagine you’re one of the cooks. How would you want the kitchen laid out? Where do you put your knife set; and you, your blender; and you, the catering cook, your cappuccino machine? How do you label your supplies so you can find them when you need them (and nobody else takes them by mistake)? What about clean up? Safety too — don’t store your cleaning fluid in the fridge!

What should such a kitchen look like in order to be easy to work in, and also allow each of you to produce different, varied, good meals for the entire week’s stay?


Well, I didn’t quite succeed. Kitchens are familiar but I’ve never seen a kitchen like this one. If you have, I’d like to hear from you. We might learn how to write better software.

Written by Tom Harris

June 30, 2006 at 4:21 am

Posted in Technology and Society

Tagged with

4 Responses

Subscribe to comments with RSS.

  1. Personally, I came upon the “software is writing a novel” concept and liked it. The similarities are clear, there is language involved, you can restructure it, generally at will, you can reorder it, you can refactor it, you can change portions of it wthout changing others (decoupled). Mostly, it is done by a single person. It comes in short (sentence), medium (short story), and long (novel) variants, much like software (script, small app, enterprise app). If a second person is involved it is more in an advisory capacity, which is generally true in software as well. Each author has his/her own style, and their own topic. Some great authors produce a single book, some produce a multitude.

    Also, the time it takes is similar, aka it’s done when it’s done. Could you imagine handing an author a task like “write me a WW2 novel” and then asking him right afterwards how long it is going to take? Obviously, that is ridiculous. Authors aren’t able to determine how long it is going to take them to craft their work. Sure, they might be able to predict how long it will take them to write a paragraph, but to refine (debug) it?

    A couple of differences: audience and sequence. The programs audience is the computer (via compiler, linker, interpreter), while a novel’s is usually a person. Also, the sequence of the novel is generally predefined. In English it’s top to bottom, left to right. It’s different in other languages. Although, the syntax and symbols differ between languages in both programming and writing.

    There’s a problem with this comparison; it doesn’t get us a lot. We can’t leverage this metaphor to learn something new about programming. No more can a great writer tell you how to do it than a great programmer can. You can learn grammar (syntax) and words (code libraries), but you can’t learn to be Shakespeare.

    I do think, though, that it can be used to put customers in the right mindset. Even non-writers know that writing a novel is hard.

    Joshua Volz

    June 30, 2006 at 10:44 am

  2. Josh,

    Thanks for your comments. Yes, coding is a lot like writing. I’ve certainly seen similarities also in that “advisory capacity” — code review similar to editorial review. And I like the implications that you bring up about work estimation.

    I wouldn’t be so pessimistic about not “learn[ing] something new about programming.” People have been writing novels, essays, and articles for a lot longer than they’ve been writing software. And there’s a lot of good writing out there. We could learn from all those writers.

    Further, though, there are some points where I actually believe something different from what you said about software, and I think those differences are important. As I see it:

    1. Most code is actually written by a team, not by one person.
    2. Accordingly, the audience of code is people more than it’s a compiler.
    3. As software is constantly being updated and re-released, it is never “done”.

    So other developers who handle the next change request have to read your code, and you have to read theirs.

    It’s more like updating the novel and republishing it every month.

    How would we have to write that kind of novel to make it work?

    Tom Harris

    June 30, 2006 at 12:27 pm

  3. […] I was still thinking about the question “What is software like?” which I tried to deal with last week in Not Like Anything You’ve Ever Seen. While I didn’t come up with a complete answer (that would be ambitious), I did think of pool. Not the swimming kind, but the kind with the pool table, sticks, and balls. Watch a professional play and you’ll see what differentiates serious pool players from the rest of us: Position play: This is the act of hitting the cue ball with the necessary speed (and spin, if needed) to get the cue ball to end up someplace on the table where you’ll be able to get the next ball in easily. In short, it’s the strategy of thinking ahead and setting up your next shot. […]

  4. […] In a recent post Tom Harris tries once again to come up with a software development metaphor. No luck this time either. But the most interesting thing about this post is its title: Not Like Anything You’ve Ever Seen. I don’t know if this was what Tom actually meant, but I think we should consider taking this title literally. Maybe software development is indeed not like any other craft we know. Maybe our attempts to find the ultimate software development metaphor are futile. […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s