Debunking the duct tape programmer

(subscribe to my feed here:

On 23 September, 2009, Joel Spolsky wrote a piece extolling the virtues of the duct tape programmer.  He contrasted the duct tape worldview to the astronaut architect.  While the astronaut architect would sit in analysis paralysis, the duct tape programmer would have some working product already out the door.

“He is the guy you want on your team building go-carts, because he has two favorite tools: duct tape and WD-40. And he will wield them elegantly even as your go-cart is careening down the hill at a mile a minute. This will happen while other programmers are still at the starting line arguing over whether to use titanium or some kind of space-age composite material that Boeing is using in the 787 Dreamliner.” – from

While indulging in analysis paralysis is certainly the downfall of some, there are more alternatives than merely pulling out duct tape and throwing something together.  We also have to keep in mind how to apply advice and from where the advice is coming.  Matt Hinze put it nicely on twitter:

“i've said it before, @jbogard : never take software advice from a bug tracking system salesman” – from

If you have small tasks, using the duct tape solution will probably serve you well.  Physical analogies are powerful, so I will stay with the duct tape metaphor.  Duct tape is strong.  It is sticky.  It is easy to apply.  On the other hand, it is not durable (it deteriorates in water and direct sunlight).  It is not removed or reapplied easily, and God help you if you get it stuck to itself.  There are good uses for the duct tape approach, and there are times when it is professional negligence.  If I’m developing an application or website for a political candidate, I’m probably fine using duct tape, but I have two constraints:

  1. I throw the whole thing away when my candidate loses.
  2. My candidate succeeds, gets more funding, and I redo the whole thing.

The argument for quick and dirty solutions is always geared toward getting the first version out quickly.  Time to market!  Time to market!  For small products, it works fine, but for larger systems, the code base can collapse on itself after a life of taking shortcuts.  This effect is well documented in the book, Clean Code

The third option, which Mr. Spolsky neglects to address, is the approach put forth by Kent Beck, in his book, Extreme Programming Explained.  I highly recommend the book, but I will quote since it is freely accessible.  While getting stuck in analysis paralysis or complex solutions is certainly not a good way to go, XP stresses Simplicity as a key principle:

“A simple design always takes less time to finish than a complex one. So always do the simplest thing that could possibly work next. If you find something that is complex replace it with something simple. It's always faster and cheaper to replace complex code now, before you waste a lot more time on it.” – from (emphasis mine)

One part of Mr. Spolsky’s premise is supported by this XP principle.  That is, if you are creating a system where a throwaway solution is appropriate (you throw away duct tape – you don’t refactor it), then that is the simplest thing that will work as you need it to.  On the other hand, if you are creating critical business applications like my company does, you want to ensure you are:

  1. Using durable materials
  2. Using malleable techniques so the 2nd, 3rd versions go well
  3. The entire system is clean (no broken windows)

The nasty truth about misapplying duct tape solutions in serious software development is that the duct tape solution ends up creating unnecessary additional complexity because it doesn’t address the whole problem, just the symptoms.  This isn’t unique to software development, but if duct tape solutions are used to achieve short term gains, then future solutions are built on a foundation of duct tape instead of some sound organizational method.  All of us have used quick and dirty fixes, but the craftsmanship quotient applies if we quickly replace the naive fix with a more organized one.  The patch panel on the left has an organization method.  The patch panel on the right has responded over time to “just one more cable” without much effort to proper organization.


The choices presented between duct tape programming and analysis paralysis are not valid.  There are many choices, and quick and dirty fixes should not be standard operating procedure (SOP).  Organized software engineering should prevail.  Approaches that apply rigorous discipline will always yield better product.  Both discipline about keeping scope under control so that you can ship quickly, and solid engineering techniques to ensure that what is shipped is maintainable for the next version.


Beating the duct programmer with generic domains, subdomains, and core domains Posted on 9.28.2009 at 5:25 AM

There has been a certain amount of noise and comment around Joel Spolsky's post on the duct tape

Alexandru Bolboaca-Diaconu (alexboly) 's status on Monday, 28-Sep-09 12:13:39 UTC - Posted on 9.28.2009 at 7:13 AM

Pingback from Alexandru Bolboaca-Diaconu (alexboly) 's status on Monday, 28-Sep-09 12:13:39 UTC -

It’s Not About The Duct Tape It’s About The People (And More) Posted on 9.28.2009 at 7:44 AM

Pingback from It’s Not About The Duct Tape It’s About The People (And More)

Weekend miscellany — The Endeavour Posted on 9.28.2009 at 8:55 AM

Pingback from Weekend miscellany — The Endeavour

nothing happens :: now i remember why i quit reading Joel On Software Posted on 9.28.2009 at 12:26 PM

Pingback from nothing happens :: now i remember why i quit reading Joel On Software

To Test or Not To Test: Not a Question! Posted on 9.29.2009 at 10:55 PM

There was a lot of noise generated by a blog “The Duct Tape Programmer” . There were lots of responses

On Crimes Against Duct-Tape, Mental Masturbation, and Pretty Boy Disclaimers | Caffeinated Coder Posted on 10.01.2009 at 8:40 AM

Pingback from On Crimes Against Duct-Tape, Mental Masturbation, and Pretty Boy Disclaimers | Caffeinated Coder

Worst Development Blog Post Ever Posted on 10.07.2009 at 9:53 PM

Worst Development Blog Post Ever

The Technical Debt of Red Green Posted on 10.10.2009 at 2:58 PM

The Technical Debt of Red Green

Herding Code 63: Victory in Software Development with K Scott Allen | Herding Code Posted on 10.24.2009 at 9:40 AM

Pingback from Herding Code 63: Victory in Software Development with K Scott Allen | Herding Code

The Imaginative Universal - October 2009: The Month that Was Posted on 11.04.2009 at 8:56 AM

Pingback from The Imaginative Universal - October 2009: The Month that Was

Duct tape programming sucks « Bavarian Cream Posted on 11.11.2009 at 3:22 PM

Pingback from Duct tape programming sucks « Bavarian Cream


Charles Feduke said on 9.25.2009 at 9:25 AM

Good article; Joel's didn't quite sit well with me when I read it. In fact I steered clear of the book he was promoting because of it.

Jon Limjap said on 9.25.2009 at 9:42 AM

This is an awesome rebutt on Joel's article Jeff.

While I'm sure Joel was, again, ranting about "smart but gets nothing done", he totally lost it and went all the way to advocating devs who are "dumb and gets things done the wrong way".

It's important to get things working, sure, but if at the end of it you're stuck with a Big Ball of Mud, it simply becomes so cumbersome you just have to throw it away at one point.

Duct tape programmers would've made Lotus Notes the way it is whether or not Ray Ozzie was there to be their architecture astronaut.

Oliver said on 9.25.2009 at 9:50 AM

I hope that is not your kid duct taped to the wall

Howard Pinsley said on 9.25.2009 at 9:51 AM

Thanks for this Jeff. You hit the nail on the head and I wholeheartedly agree.

Jeffrey Palermo said on 9.25.2009 at 9:57 AM


Ha! nope. not my kid.

Kevin said on 9.25.2009 at 10:16 AM

How did you get a picture of our server room you have on the right!!! :-)

NotMyself said on 9.25.2009 at 10:23 AM

I wonder ifthe differences in opinion that you have with Joel come from the nature of your businesses. My understanding is that Headspring primarilally does contract work and FogCreek does boxed software. It seems the perspective of having to sell something you have already spent time and money on would lean toward the duct tape method. Where as a contracting outfit has already agreed on a price (for the most part) and are working do deliver something for which they have already been paid.

Steve Jones said on 9.25.2009 at 10:23 AM

Nice writeup. I took something different from Joel's article. Not that every system should be thrown together, but that it needs to move and get going. Go with simpler solutions and get them out the door. Then start fixing them. I didn't have the impression that he expected these programs to live forever, but that they would need to be refactored over time, given feedback from users.

I also thought the end of his article was telling in that it says not everyone can be a duct tape programmer. I think that's true. There are some very, very good coders that can take this approach and get things done quickly, but most developers will end up throwing out slop.

Your rebuttal addresses a certain situation, with larger pieces of software, and I think it's valid. I'm not sure how many people work with small solutions rather than large ones, but I do find that many developers do want to over-engineer and over-polish a product at the expense of getting it done. Either in corporate applications or shrink wrap.

Paul Cowan said on 9.25.2009 at 10:25 AM

The bigger the company the more detched you become from the realities of actually shipping sofware that can generate money.

I generally prefer to contract for smaller companies where you can actually see the inner workings of the company.

Unfortunately I have also worked on websites where certain idiots have used irrelevant practices for the size of the application like DDD. One such web application had bounded contexts before it had web page. It was months late and we had a domain model before an HTML prototype.

A lot of developers work on web applications. Most developers get very hot and bothered about clean code and test coverage. Funny how we never talk about the usability and simplicity of he external solution. It is all inward facing. Clean code never sold a product.

Where clean code does come into it's own is allowing the product to be flexible and react to feedback. But getting the product out there and incurring some technical debt in order to react to the much more needed feedback is ultra important.

How come we are so concerned with the inward facing product than the one that is in the hands of our users?

Patrick Steele said on 9.25.2009 at 10:25 AM

Very nice follow-up to Joel's article. Kudos!

Jim said on 9.25.2009 at 3:19 PM

Joel is a founder/CEO/president or whatever, he is not a programmer. He wants things to ship on time or early and he wants to make money. Of course he prefers the coders who get things done quickly - they make him (and his company) more money.

In a lot of industries time to market is much more important than what your code looks like. It all depends on your industry.

Jeffrey Palermo said on 9.25.2009 at 3:37 PM


Everyone. . . EVERYONE. . .prefers the programmers who ship things more quickly. From there, other factors come in.

Stephen Brown said on 9.25.2009 at 4:53 PM

This article was really about YAGNI and not overdesigning everything from the get-go. This is a core agile principle and I don't think Joel was advocating that you write crappy code, just that you don't make everything all complicated before you need to.

Also, he was a programmer and software designer for quite a while to those who try to claim he's just a salesman. I'm not a real MS fan or anything, but he was program manager on VBA, and that's serious chops.

Basically, this was just a rail against astronaut architecture, and not an advocation of hackery.

Ricardo said on 9.25.2009 at 7:41 PM

Jeffrey, I think that in reality most of all programmers and developers fall somewhere in the middle, most of the times for one reason or another we don't seem have time to learn nor to do all of the complicated stuff that many books, architectures and design patterns tell us to do, and in the other hand, we also do not just put something together and release it because we all know that stuff like that will always come back to us and it will be complicated and time consuming to fix it. Maybe the approach of simple designs, simple architecture, and just enough test coverage in the areas that are really important is the key to success.

I read Joel's article and what I got from it is that "Duct Tape Programmers" are very valuable as in they are the ones who actually sit down and start writing simple quality code, without over engineering it, thus helping the bottom line by getting the software product out the door quickly.

Joel never mentioned that these programmers always do "quick and dirty fixes" to get the product out, they just don't waste time walking around, with their nose in a book and in conferences trying to figure it out what design pattern and architecture to use next.

I do not agree 100% with Joel either, I do appreciate a project with good test coverage because it helps those "Duct Tape Programmers" feel confident about their code when making changes to it and thus they check in their code quickly... after making sure all tests passed.

I am against over engineered applications, and that is in my opinion what Joel referred to when talking about that book, it seems to me that most of the times the software architects are so far from the coding and the programmers that they loose touch with reality when architecting and designing the complex systems that we all dislike.

In the end, it is all about following the KISS principle to software programming and in reality to everything else we do.

PM-SilverCrux said on 9.26.2009 at 10:41 AM

Is it me or everyone else here who feels Joel does bring up these controversial topics once a quarter ? This to keep all his sites popular(negative or positive!). Now he will probably spend an hour on talking over this, in his podcast. This seems to be a nice business strategy that's working well for him :).

Truth is balance. Every programmer needs to find his own balance depending on what he is trying to achieve, given the constraints.

kwarizmi said on 9.28.2009 at 8:30 AM

"We also have to keep in mind how to apply advice and from where the advice is coming. "

This is the genetic fallacy. From Wikipedia (

"The genetic fallacy is a fallacy of irrelevance where a conclusion is suggested based solely on something or someone's origin rather than its current meaning or context. This overlooks any difference to be found in the present situation, typically transferring the positive or negative esteem from the earlier context.

The fallacy therefore fails to assess the claim on its merit. The first criterion of a good argument is that the premises must have bearing on the truth or falsity of the claim in question.[1] Genetic accounts of an issue may be true, and they may help illuminate the reasons why the issue has assumed its present form, but they are irrelevant to its merits."

John Cromartie said on 9.28.2009 at 8:39 AM

I view the Unix Philosophy ( as being the best example of "duct tape programming." It means solving small problems with the most appropriate solution at hand.

Richard said on 9.28.2009 at 8:57 AM

Joel has a whole article about why you should never rewrite something - only refactor it.

So start with duct tape, never throw it away.

He also has an article about pragmatists, who remain backward compatible and put in exceptions to maintain the oldest dependent code.

So start with duct tape, don't throw it away, add more duct tape.

Sound like any software company you can think of?

Dippy Dog said on 9.28.2009 at 9:04 AM

From the "There, I Fixed It" blog...

From my experience, upper management never realizes that the expensive fixes we do now are a direct result of the cheap construction of the system foundations done previously. They can't relate the two.

Caleb Jenkins said on 9.28.2009 at 9:39 AM

Well put Jeffrey. I'll always concerned when people speak in such absolutes like Joel. Like you said, sometimes duck tape is a valid approach... but it should never be the default! Awesome.

Joe said on 9.28.2009 at 10:27 AM

I'm continually surprised at the defense that Joel was really just preaching that reducing complexity is good. Perhaps Joel believes that, but that's not what he wrote and we have to take what he wrote at face value. Aside from other criticisms, Joel supported the claim that multi-threading, C++ and any other "advanced" technology should be eschewed in part because "nobody" is smart enough to use them. (To make the article even more bizarre, the man Joel holds up as the pinnacle of great programming was partly responsible for the early iterations of Netscape which, if anyone besides me remembers, was horrible--for one, you could start it, do nothing and it would eventually consume all the memory on your system. IIRC, the whole point of Firefox is that the REWROTE the entire damn thing.)

Steve Webb said on 9.28.2009 at 11:29 AM

I tend to think of startups as "Duct-tape Programming". Lots of things are thrown together quickly, cabling looks like the image on the right-hand-side in your article, things are not pretty, but they work and functionality is demonstratable. However, successful companies don't stay in start-up mode forever. They eventually become profitable and at that point, many engineers of all kinds change from start-up mode to 'real company' mode. Then the duct tape gets replaced by real, quality, thought-out engineering. Money is spent, cabling gets re-wired, etc ...

There is a time for duct-tape engineering, and a time for thoroughly engineered change, it just depends on where your company or project is in its evolution.

Dagfinn Reiersøl said on 9.28.2009 at 2:06 PM

I think of Joel's article as "duct tape blogging". If you read it carefully, it's not really logically consistent. Software development is either duct tape or architectural astronaut, but neither is achievable by ordinary programmers if you take him literally. This kind of inconsistency means that everybody can take something different from it and disagree about what he actually said. Like most holy scriptures.

Nick said on 9.28.2009 at 3:04 PM

@Someone: Don't you mean "just give it a REST"? ;)

Steve said on 9.28.2009 at 7:23 PM

You didn't add much to the mix dude. Shameless plug

Dino said on 9.29.2009 at 7:08 AM

Since we are in the realm of bad analogies, Duct Tape Programmer meet Duct Tape Builder:

Withheld said on 9.29.2009 at 11:04 AM

I think it's the metaphor that really trips up the discussion. Duct tape isn't an apt analogy. If you have to use a metaphor it's more about the guy with a tool box full of trusty tools that rarely fail, versus the guy with a garage full of expensive machinery and shiny brittle tools that he spent money on so by golly he's going to use it!

It's all about perspective. If you've worked in a company where it's dominated by the multiple-inheritance, bleeding edge everything, dozens of empty classes, etc. approach (with no product to show for it). You know that you need someone to say "Cut it out! We need to ship something! Stop hyper analyzing it! There are plenty of normal, simple patterns we can use that will get the job done."

Josie Célibataire said on 10.08.2009 at 7:43 AM

I used to work for a firm full of this kind of people and just couldn't stand it - so I just quit by saying "you seem to know how to do it way better than me, just do it yourself then"

Steve Piccolo said on 10.12.2009 at 1:04 PM

It's pretty funny that Joel uses Netscape as the ideal example. Hmmm...that software was good while it lasted but apparently the duct tape approach didn't work in the long term. It hasn't been around in years. Or if you call Firefox a descendant of it, you also have to admit that it took years to revamp that duct tape code.

Though in a sense I can see what he's saying. He just goes too far to the extreme and generalizes too much.

Zocken Internet said on 3.11.2010 at 1:28 AM

This post isn't meant to be about domain-driven design, and, like you mentioned, there are many different definitions. The industry hasn't been able to agree on the exact details of a definition, so I don't presume to expect that here. Thanks for the comment. I really appreciate your feedback.