About a month ago, Joel Spolsky had the software developer community up in arms over his article, “The Duct Tape Programmer“.  Everyone with a blog felt compelled to throw in their knee-jerk response, faithfully declaring their allegiance to either Joel and the duct tape crowd or the do-it-right crowd.  And as so frequently happens on the internet, the whole argument degenerated into an enormous straw man fight.  Duct tape programmers complained about how endlessly debating best practices and writing unit tests doesn’t get anything done, while do-it-right programmers argued that poor design leads to maintenance nightmares down the line.  Both assertions are correct of course, but they miss out on one key point: there’s no such thing as a duct tape programmer.

To expand on Joel’s analogy, you won’t find a carpenter who only uses duct tape to fix things.  Similarly, you also won’t find a carpenter who doesn’t know how to use duct tape or refuses to use it under any circumstances.  All carpenters have duct tape in their toolbox. What differentiates a good carpenter from a bad one isn’t whether they use duct tape, it’s how well they use it and when they choose to use it.

Bringing this back into software terminology, there are situations where delivering code quickly is more important than delivering it correctly.  Yes, even if it means there are bugs.  Yes, even if it means maintenance will be a nightmare.  For instance, when your team is in a race against other competitors to be the first one out the door (e.g. iPhone development, Facebook app development) or when deadlines absolutely, positively must be met (e.g. your company will be sued if it doesn’t meet some compliance issue by a certain date or you’ll lose a potential client if a certain feature isn’t implemented by their go-live date).  In situations like these, getting things done trumps anything else and if it has to come at the cost of good coding practices, then so be it.

But — and this is a big but — , these situations are the exception, not the rule.  The difference between a good developer and a bad developer isn’t whether they use duct tape, it’s how well they can recognize whether a situation calls for it.  Bad developers use duct tape far too often, either because they’re too lazy to implement something correctly or because they simply don’t know of any other way to do it.  Good developers keep their duct tape handy for when they need it, but are usually smart enough to come up with better solutions instead.

9 responses to There’s No Such Thing As A Duct Tape Programmer

  1. John Farrell said:

    You turned an nuanced article covering a very complicated topic into a simplistic metaphor. Then debated the metaphor and declared victory.

    Finally you shuffled out the good old "no silver bullet" point of view and smelled the napalm in the air.

    I don’t see any substance here.

  2. Kevin Pang said:


    You’re right that there isn’t much substance here, but only because there wasn’t much substance to begin with. The "no silver bullet" point was the point that Joel was making to begin with. The problem I had was with the subsequent blog posts it spawned, which turned into a black-and-white all-or-nothing argument.

    As for the metaphor, all I did was expand on it. The original post was already taking a complicated topic and turning it into a simplistic metaphor. I wasn’t debating the metaphor so much as all the criticism and support of it.

    I appreciate the reply though. Makes me think that perhaps I wasn’t making my points clear enough.

  3. @Kevin said:


    Have you checked out the latest Stackoverflow.com podcast? Joel explains the duct tape concept a bit more and it deepened my understanding of what he meant.

  4. Kevin Pang said:


    No, I haven’t had a chance to. I’ve fallen pretty far back on my podcasts (still listening to some from 6+ months ago!) due to having a new baby. I’ll get around to it though! :-)

    To be clear, I actually had no problem with his post (unlike most of the people who have replied to it). I think I understood the gist of it, but I could be mistaken. This post was a response to the bloggers who replied to Joel, essentially proclaiming him and his mindset as the root of all software problems in our industry.

  5. Twylite said:

    You’re still missing the point (and building strawmen). You equate "duct-tape programmer" with "quick & dirty hack".

    Joel defined what he chose (perhaps wrongly) to call a "duct-tape programmer" as someone who is pragmatic; eschews over-engineering in favor of simple, comprehensible tools & methods; and focuses on the goal of producing shippable functionality ahead of the surrogate goal of "pretty", supposedly maintainable code.

  6. Rob said:

    I have to be blunt – [b]who really gives a crap?![/b] The zealots on either side are not going to change their attitude. And those in the middle will do whatever they feel is right [i]for them[/i].

    For me, "KISS is Bliss" – Build working software. How the hell you like. If it’s good, and I can use it to make my life better – I will pay for it, I don’t [i]care[/i] what practices you used. If it’s bad or [i]becomes[/i] bad (e.g maintenance slows) then I will [b]stop[/b] paying for it.


  7. Dave said:


    you clearly "Give a crap"

    [quote]If it … becomes bad (e.g maintenance slows) then I will [b]stop[/b] paying for it.[/quote]

  8. Erik Burns said:

    Great post Kevin! Seems we all read that Spolksy article. I too enjoyed it, but IMO your analysis seems more balanced and generally sound. The reality is that both approaches can win or lose. Obviously duct-tape IS an interesting metaphor since you can’t build much of a foundation out of duct-tape.

    As programmers and designers we all face this challenge on a daily basis – do it quick or do it right. This is especially true in the startup world where everything is changing quickly, but you are trying to build core value. Both approaches can be correct and how you answer them day in and day out defines your fabric as a professional.

    Joel’s job is to ignite a fire via a slightly one-sided stand. Thanks for a well-written balanced response to that concept.

  9. rkeurel said:

    While I agree in general with what you are saying, it seems to me that the people on the side of craftsmanship are only being so zealous because they want to drive the point home. The fact of the matter is that the majority of developers use “duck tape” too often and it is not necessarily due to a lack of intelligence, but of discipline. Most of the time, the problem is simply that outside of certain circles, things like design patterns, architectural principles such as SOLID, best practices such as unit testing and continuous integration, and even things like knowing how to use your tech (many people don’t take the time to properly understand basic things like JavaScript, HTML, CSS, Unicode) are simply labeled as impractical right off hand because first of all, they are not necessary to produce a solution, second, for most people they may require a big time investment, and third, many of these things have a learning curve at the beginning of which what you are doing may not make sense. Despite all this, best practices should be the norm, not some ideal that only the best and brightest adhere to. In this context, I feel it is correct for us as professionals to get on the case of another professional when they try to rationalize not doing things correctly because of constraints. It doesn’t matter what your reasons are, you will always find an excuse to not do something a better way unless you develop some discipline.