In http://www.joelonsoftware.com/items/2009/09/23.html, Joel Spolsky of the Joel on Software Blog advocates a practice he calls “Duct Tape Programming.” What he advocates actually is nothing new. It’s more commonly known as “Cowboy Coding.” I decided to post my response for public comment.

Joel’s article was amusing, but obviously balance is important.

I got the impression the Joel was rebelling against COM, C++, OOP, and general abstraction. I can’t say I personally share his view that complex technology is inherently bad. These features are sharp tools, much like the power tools today’s carpenter uses to build a house. Left in the hands of idiots, sharp tools cause problems. It doesn’t take too much imagination to see how assigning an idiot with a drinking problem and an addiction to cough syrup with the task of ripping boards (cutting lengthwise) with a table saw can cause problems. Likewise, letting someone write multi-threaded code who doesn’t have the skill necessary to handle it responsibly is a recipe for disaster.

Over-engineering is a serious threat to a business, especially since many engineers I have worked with can fairly be accused of over-engineering at some point or another in his or her career. However, there’s obviously a reason things like Object Oriented Programming exist… and it isn’t just because the entire software engineering profession isn’t as smart as Mr. Macho Duct Tape Cowboy.

Everyone reading this who has written code for a large company has seen what happens when duct tape programming gets taken too far.  You end up with a giant legacy system, written by two-dozen authors over multiple decades. The application performs poorly, is difficult to maintain, and no one has holistic knowledge of how the system works. You often find yourself spending 6 months training each engineer which touches the system on your internal proprietary duct tape patterns. Duct tape programming is fine and dandy until you ship something that’s broken or can’t be extended to fit your changing business needs — because it is a giant scary monolith and every simple change in one piece of functionality breaks another piece that was duct-taped on it 5 years ago.

OOP and standardization technologies that abstract complexity pay off when you have more developers that can fit comfortably in a small office and you realistically expect for a product to be handled in the future by people other than its original authors. They add complexity for the sake of compartmentalizing functionality so it can be distributed among different authors and can encourage documentation of the workings of each module.

My team pushes for modern standards and best practices so that we can hire a sharp developer who’s familiar with modern technology, and he can instantly understand most of what we’re doing. More often than not, we could have shipped whatever we were working on slightly faster if we ignored standardization and just did things the way we did them many years ago because it was familiar to us. However, the customer would pay the price when they asked someone other than us to maintain our quickly-shipped, duct-taped masterpiece.

Most professional developers write code for a company for the sake of delivering a quality application, a tool to enhance their business. You do the client no favor by saving them money on the initial delivery and costing them more down the road to keep the product running and relevant… unless you’re solely billing by the hour and are in a situation where they can never fire or sue you.

Clearly this is a complex problem that people are years from solving, but until the geniuses of the world get together and solve this once and for all, I personally think we’re best off balancing writing elegant, standards-compliant code with shipping things on time and not blindly adopting technology without fully understanding the consequences.