Journey vs. Destination

I compared algorithms to recipes not too long ago. But I wanted to write a post about test driven development (TDD) and how every time I rediscover it, I think that it is great. So I was thinking about how to explain TDD to someone who doesn’t work with computers. And that was when I realized that just explaining how to program is not that easy.

I think of programming as writing: writing a story that is supposed to evoke a particular response from a given audience. Let’s say you had a young girl and you wanted her to smile, giggle, gasp, cry and then smile (with eye crinkles!). Other than those five actions, you don’t care what she does, but you need all five in, say, 15 minutes.

Once upon a time, there was a princess. She looked a lot like you! Her name… sotto, what is your name? Violet? Oh, that is beautiful! And you know what, her name was Violet too: Princess Violet Purple Lavender!

Ok, so I bet I’ve knocked off the first two responses there. But I’d have to try it out. I’d have to find a girl (named Violet) and tell her my story-let. And then, if it didn’t work, I’d have to erase her memory and try again.  And let’s pretend I could keep erasing and keep trying out stories until I got my five small emotional outbursts, all in order, all in my allotted time.

I may have to learn more about her to accomplish my task? What makes her scared? Is that the best way to elicit a gasp?  This information may be useful in crafting other stories for other children (or it may not, Violet may be oddly singular). And how I choose to go about this is very personal to me. I’d rather she gasped in surprise than terror. Given the current specification, I have that option.

There are lots of other stories out there, I might crib information from some of them and I might admire the elegant solutions or particularly fine writing. If a story ending isn’t copyrighted and is good for eliciting big smiles, well, I may use it myself, either wholesale or adapting it to the rest of my tale.

When I write programs, I’m telling the computer a story to get it to do what I want. There are lots and lots of ways to do it. Some ways are easier, some ways are considered better (if your Violet is young enough, you might get a gasp by dropping the F-bomb randomly but how are you going to get back to a smile from there?).

Sometimes I do have to figure out how to trick the computer into the action I want, very much like a puzzle. And sometimes I have each action as a preformed Lego block from some other story and I just need to find a good way to hook them together. That can be a puzzle too, especially if they don’t quite fit together (this one has a dragon, that one has a sea monster).

Finally, when I write my story, I’m not only writing for my audience but also for other writers. That story drivel above is clear and understandable but it isn’t great literature. I don’t know that I want to write great literature. But something with a little more craft would please me and any fellow writers who have to read my stories (err… fellow software engineers who have to read my code). It is kind of like the Anamaniacs cartoon where there were jokes for the kiddies and then there was another level of humor for the adults watching. The programs are for the computers and for the other programmers. A lot of programmers forget that.

I could ride this poor metaphor pretty far, but does it make sense to you? I don’t think I’ve represented the square-hole-in-a-round-peg problem-solving and puzzle aspect of it well enough so maybe I need an entirely different metaphor or I need to work in the poetry aspect to it. But then getting a kid to do what you want is often a pretty big puzzle. Anyway, if you program, how would you describe it to someone who didn’t?