The concept of technical debt (first coined by Ward Cunningham) has been something that has wandered about my head without a name for quite some time. The other day I read an article that finally put it into words. It is what I have always seen as the reason writing beautiful code is not just an endeavor in aesthetics. At this point you’re probably wondering what the heck I’m rambling on about. Don’t give up on me yet, I’m about to explain . . .

For most developers, time is a commodity that is often scarce and very expensive for our employers. With a resource in such high demand, it is no surprise that there is a temptation to do what we can to conserve it. Certainly there is nothing wrong with being efficient, but there is also a point at which efficiency ends and technical debt begins. Technical debt is created when we start to write sloppy code, “hacks,” or make other wreckless time-saving maneuvers. While we may save time in the immediate future, we are actually incurring a debt that will eventually have to be repaid, with interest.

The interest basically encompasses the extra time and effort we have to spend fixing bugs and making improvements as a result of the earlier shortcuts that were made. Just like financial debt, technical debt can be paid off. This is done through code rewrites and corrections to bring the quick-and-dirty code up to snuff. The longer we leave the debt unpaid, the more the interest grows until it ultimately can bring a development team to its knees.

Technical debt can actually be a useful tool, if handled responsibly. You can choose the quick-and-dirty route to save time and meet a deadline, and then later repay that debt by fixing the code afterwards. This way you can release planned functionality on-time and “save face” if you are developing software for a client or third party. Be weary of this practice though, while clients may only be concerned that something “works” they will also be the first ones to complain when something goes wrong and it takes you unusually long to fix it. Just like a credit card, this approach requires that you follow through with your obligation to repay your balance later.

So the next time you’re deep into a project and you think “I could throw something together in 5 minutes and everything will work” don’t forget that the 5 minutes you saved could cost you hours six months later when a client requests new features or bug fixes. Make sure it’s a debt you are able and willing to repay.