(subscribe to my feed here: http://feeds.jeffreypalermo.com/jeffreypalermo)
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 http://www.joelonsoftware.com/items/2009/09/23.html
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 http://twitter.com/mhinze/status/4341230362
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:
- I throw the whole thing away when my candidate loses.
- 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 extremeprogramming.org 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 http://www.extremeprogramming.org/rules/simple.html (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:
- Using durable materials
- Using malleable techniques so the 2nd, 3rd versions go well
- 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.
Conclusion
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.
