Are Duct Tape programmers a good thing?

25. October 2009

In a relatively recent post by Joel, he pines poetic about "duct tape" programmers that "just get stuff done." 

All business endeavors come down to cost-benefit analysis. Writing code with bailing wire and 3-in-1 oil is no different. The cost of writing spaghetti code is always in the maintenance and reporting not in the initial release. How many customers will have this code? If the application is purely one off for one installation point or one customer and will never be reported against, then the benefit of releasing "something" more than covers the cost. How often does that type of project come along: one installation point and/or one customer, zero maintenance responsibility, zero reporting?

Writing code that is difficult to maintain adds orders of magnitude to the cost. If there are many installation points, then the cost rises exponentially with the number of installations.

In my experience, the "just get it done" developers generally never look to the future. They never ask questions about maintenance or reporting. Typically, they swoop in, write the magic widget with no care about code quality or maintainability, bask in the warmth of hero worship for "getting it done" and move on before anyone has discovered the cluster f- they created. If your company is really unlucky, "the day" comes when it is realized that said duct tape developers' solution only "looked" right but in reality had several critical flaws that bring down the company. I have been a witness to this exact scenario (thankfully, it wasn't my code) and it wasn't pretty.

In my experience, I find that people that just want "get it done" developers do not account for all the things that actually need to be done.

.NET Development, Developer Skills, Unintended Consequences

blog comments powered by Disqus