Technical Debt

August 16, 2012

While on site at a client the other day, I heard one of the FTEs make the statement about their brand new legacy application that “there was too much technical debt, so it needed to be rewritten”. I cringed a little bit, but I considered that I was just being pedantic, and decided not to nit-pick at the misuse of the term “technical debt”. Looking back, I’m not sure I should have let that statement go. I probably should have shed light on the important distinction that should be made between accruing technical debt and creating a mess.

Technical debt is the result of an engineer being faced with the choice of the appropriate design decision at the time, or some other favorable outcome (usually short-term), and consciously deciding to go with the latter. Accruing technical debt is intentional, like using a credit card. It’s a decision to get a result without contributing the effort necessary to earn the result, but always with the intention of paying it down. Just like with credit, if the debtor is good at managing their technical finances, they should be able to easily avoid falling into overwhelming debt, usually resulting in having to negotiate with bill collectors (management) and occasionally resulting in declaring bankruptcy (a rewrite).

A mess, on the other hand, is an unmitigated river of a bad decisions devoid of any discernible amount of discretion. It is bad decision making without rhyme or reason, and is typically perpetuated by engineers who have no context or frame of reference by which to measure a good design decision over a poor one. Messes are extremely dangerous, because they point to a competency or professionalism problem, and almost always result in a rewrite, the scale of which is proportional to how intricately the mess has been woven into the fabric fibers of the application. Look at your code, and focus on the parts that disturb you. Check the author’s other commits. Make sure they were intentional and temporary, and hopefully annotated with a TODO. Otherwise, you might find yourself declaring bankruptcy on behalf of someone else’s mistakes.


John is a serial conversationalist who spends entirely too much time engulfed in problem domains he knows nothing about and has no earthly business trying to learn. He can occasionally be found at your local coffee shop writing algorithms and trying to think deep thoughts.