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.