One of the most common metaphors used to describe programming is that it is like writing.  While this is a good metaphor, it is lacking at times, as others have pointed out.  So, while in the shower (when many great ideas can be had, because taking a shower isn’t a mentally taxing activity), I let my mind wander and started trying to think of a better metaphor for programming.  I think I came up with one.

It isn’t a different metaphor from writing, but is instead an extension of the metaphor.  It’s a refinement that will allow you to explain to people who have no clue what it is you do all day, like your mother or father.

Tell Mom that programming is like writing a manual.  Okay, so this metaphor has been used before and isn’t completely new.  But the devil is in the details, so lets explore how programming is like a writing a manual.

First, lets assume that you actually read the manual.  Most people don’t, at least at first, but computers don’t have a choice.  They have to read the directions we give them, at least until they become sentient, which has a chance of happening tomorrow, but isn’t likely.  In the mean time, they still need their manuals, their programs.

So why do you read the manual?  To tell you how to do something.  If the manual is well written, in a language you understand, you get the related task done more quickly.  If the manual is poorly written, it takes you longer to complete the task.  If the manual happens to be in another language, without pictures, you might never complete the task.

Let’s delve a little deeper.

You just bought your child a tricycle and there is some assembly required.  Using the manual, you easily build the tricycle, and your child loves you and happily kisses you good night.

A few years later, you upgrade.  You’ve now bought your child a bike, again, with some assembly required.  Maybe it comes with a cool horn that wasn’t attached.  And you have to put the wheels on, because you ordered it off of Amazon and didn’t buy it at Target.  But you can’t find the directions.  While rummaging around in the garage for a screw driver you find the tricycle instructions.  You notice they look like they might work for the bike.  Not an exact match, but they might help you out, so you use them.  All works out in the end, and your child is once again happy, but you don’t get a good night kiss this time, because they’ve hit the preteen stage and that kind of thing just isn’t cool any more.

Now a couple more years pass.  Your child doesn’t ride bikes any more and wonders when you’re going to buy them a car.  You of course prefer not to get them a car until they at least turn 16, but in the mean time you’re concerned about your health, so you’ve ordered a bike for yourself off of Amazon.  This time when you open it the instructions fall into your lap, and you easily assemble the bike. You then go for a long ride, which you regret afterwards, as you feel horribly sore and realize you are terribly out of shape.  Your spouse gives you a good night kiss to make you feel better.

Now, I hope you found that story interesting.  But what does it have to do with computers and programming?  Like I mentioned before, the devil’s in the details.  The progression of the manual in this story represents the progression of the programs you write.  Perhaps at first you write the tricycle manual.  It’s the small program that makes the system work.  But someday you’re going to upgrade to a bike.  The tricycle manual really doesn’t cut it any more, but it’s all you have, so you work with it until you’ve final written the bike manual that you need.  And of course, when the design of the bike changes you’ll need to change the manual as well.

Everything you do, from creation of a program, to maintenance, to cursing the terrible programmer who came before you, is captured in this metaphor.  Okay, the cursing isn’t in the story as I told it, but if you mention getting your finger caught in the bike chain, it could be.

Try it out sometime.  Tell your mother or father that what you do is write manuals (highly technical manuals).  While they still might wonder exactly what it is you do, they’ll at least have a much better idea.

If you think this metaphor could be better, or you have your own, let me know.  There’s always more than one way to express an idea.