jump to navigation

Comments on Joel Spolsky’s “The Duct Tape Programmer” 28 September 2009

Posted by manniwood in Programming.
trackback

I blogged not too long ago about heroic programming, and how when I was younger, I thought Real Programmers used Real Languages like C. Real Programmers littered their code with Difficult Stuff like memory allocation and crazy pointer arithmetic. Yet as I gained experience and looked at the architecture of open source projects I admired, I saw that Real Programmers actually cordoned off the difficult stuff and were confident enough in their own skills to not feel the need to show off. Real Programmers embraced simplicity and elegance (which is sometimes actually harder than just picking a couple of design patterns out of a book and hammering them into shape to fit your problem).

I thought that Joel Spolsky’s The Duct Tape Programmer was going in the same direction:

One principle duct tape programmers understand well is that any kind of coding technique that’s even slightly complicated is going to doom your project. Duct tape programmers tend to avoid C++, templates, multiple inheritance, multithreading, COM, CORBA, and a host of other technologies that are all totally reasonable, when you think long and hard about them, but are, honestly, just a little bit too hard for the human brain.

George Orwell said: “Never use a long word where a short one will do.” Orwell thought people who are trying to hide something, or who lack the conviction of their beliefs, hide behind large words and flowery, indirect language. I’ve always suspected that over-architected, baroque codebases hide something too.

So you would think that Spolsky would conclude his essay with “therefore, we should all try to be a bit more like duct tape programmers: while we do not want to write messy code or bad code, we do want to write simple code and not embrace complexity for its own sake. We should not be embarrassed when we do the simplest thing possible. We do not need to show off our programming chops at every turn. It’s OK to admit there was an easy solution and ship on time.”

But Spolsky does not say this. Instead, he concludes with:

One thing you have to be careful about, though, is that duct tape programmers are the software world equivalent of pretty boys… those breathtakingly good-looking young men who can roll out of bed, without shaving, without combing their hair, and without brushing their teeth, and get on the subway in yesterday’s dirty clothes and look beautiful, because that’s who they are. You, my friend, cannot go out in public without combing your hair. It will frighten the children. Because you’re just not that pretty. Duct tape programmers have to have a lot of talent to pull off this shtick. They have to be good enough programmers to ship code, and we’ll forgive them if they never write a unit test, or if they xor the “next” and “prev” pointers of their linked list into a single DWORD to save 32 bits, because they’re pretty enough, and smart enough, to pull it off.

Really? Because I thought the programmers who aren’t clever/silly enough to xor their “next” and “prev” pointers should especially try to emulate the best attributes of Duct Tape Programmers. Instead of hiding behind technologies that “are, honestly, just a little bit too hard for the human brain”, regular programmers should also try to just think hard about what it is they are trying to solve, and do it in the simplest, cleanest way possible.

I agree with Spolsky that whereas Duct Tape Programmers use every trick in the book to ship code fast, the average programmer should avoid those tricks. Makes sense to me.

But where Spolsky goes off the rails is implying that average programmers should also avoid the good habits of Duct Tape Programmers, like doing the simplest thing possible. Avoiding difficulty for its own sake (or out of a need to show off; or out of the need to follow a “best practice”) is not a clever trick reserved to the programming elite. It’s sound advice that should especially be followed by mere programming mortals, to keep them out of trouble, and to help them meet their deadlines.

Comments»

No comments yet — be the first.