The Duct-Tape Programmer Explained

by Krishna on October 2, 2009

Hope you had the time to read through all the essays linked to in yesterday's post about the reactions to Joel Spolsky’s article “The Duct-Tape Programmer”. Here is my take on it.

The use of the words “Duct-Tape” was only chosen by Joel as a flame bait, as he admits on his Twitter feed. Joel has a history of using colorful terms (like architecture astronauts) to represent concepts (and get reactions) and this was just one of them. People need to get over the post title and look at what he was trying to say.

What Joel intended to say (I presume) was, “Program with the tools and technologies you know instead of choosing exotic and less-understood technologies and methodologies”. That is a sane, non-controversial statement that you can apply to most software development, because it reduces the risk of failure by using unproven software components.

Joel is also right in pointing out that many programmers are afraid to say “No” to the latest stuff because they are “too afraid of looking stupid”. Programmers are proud people and they hate to admit that they don’t know something. They are also eager to try out new things. When you have a person in the team strongly advocating something new, they want to investigate it. That doesn’t necessarily mean it is going to fail, especially if the new technology is helpful. It is just that nobody knows any better until they try it.

But Joel is wrong in saying, “any kind of coding technique that’s even slightly complicated is going to doom your project”. That is too broad a statement and, taken at face value, it essentially justifies learning nothing new. Every new technique always comes with a learning curve that you have to get through to master it. The issue is: How much of a learning curve is it and what is the cost-benefit in terms of development speed?

For example, take a technology like ORM (object-relational mapping) or a better unit testing framework. You can build a perfectly working application without them and using your existing tools. And you could also build one using them, but let’s say you have to learn. You may be able to save time in the long run, but you have deadlines to meet. So what do you do? Well, if the deadlines are further off, you could make an effort to understand the technology and see if you are comfortable enough to use it. On the other hand, if your release dates are very close and non-negotiable, maybe you should try experimenting on another project. Maybe learn it in your spare time so that you are ready to use in your next project.

As for the reactions, on a second reading, I felt Uncle Bob's take on it very even-handed. Cedric launched an unnecessary attack on Uncle Bob, but he had some other good points about Agile inflexibility (To self: future post perhaps). As for linking Joel with StackOverflow, Jeff Atwood, not Joel, deserves most of the credit. Also, don’t forget that StackOverflow used some of the latest technologies (ASP.NET MVC and Linq-to-SQL) that the developers were not familiar with when they started coding. Now, they did go past the initial deadlines that they had set, but despite great transparency about what they were doing, no competitor emerged.

Now, Joel’s post is surprising in the context of FogBugz. The thing is, FogBugz has been around for a long, long time (since 2001). But Joel continues to write “Shipping is a feature”, almost as if he is paranoid about some competitor of FogBugz. And he frequently writes about people who talk to him about some new stuff, with his description of the guy with the coffee mug in hand coming to his office sounding a bit too detailed to be fictitious. So is this some kind of internal FogCreek debate about the existing FogBugz design?

Comments on this entry are closed.

Previous post:

Next post: