The term “technical debt” has a tendency to evoke an emotional response. Some people react puritanically – “technical debt” means sloppy code; sloppy code is sin; failing to call sin “sin” is condoning sin; to the stake with the heretic! Others will contend that technical debt solely refers solely to conscious trade-offs and by definition excludes code that is poorly written or designed. This faction will often refer to Ward Cunningham’s explanation of the metaphor (obviously canonical since Ward coined the term):
“A lot of bloggers at least have explained the debt metaphor and confused it, I think, with the idea that you could write code poorly with the intention of doing a good job later and thinking that that was the primary source of debt.
I’m never in favor of writing code poorly, but I am in favor of writing code to reflect your current understanding of a problem even if that understanding is partial.
You know, if you want to be able to go into debt that way by developing software that you don’t completely understand, you are wise to make that software reflect your understanding as best as you can, so that when it does come time to refactor, it’s clear what you were thinking when you wrote it, making it easier to refactor it into what your current thinking is now.
In other words, the whole debt metaphor, let’s say, the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem.”
While this explanation speaks to Cunningham’s mindset around the proper use of technical debt (“…developing software that you don’t completely understand…”), it doesn’t preclude other issues falling within the definition. In fact, his assertion that “…the ability to pay back debt, and make the debt metaphor work for your advantage depends upon your writing code that is clean enough to be able to refactor as you come to understand your problem,” implies that sloppy code is debt that is harder to pay back and make work to your advantage.
A more expansive definition of the metaphor just makes sense. Martin Fowler, in a recent exchange on Twitter, stated “For me the usefulness of the debt metaphor is what we do with it: pay the interest or pay down the principal”. He also noted “…that’s why sloppiness == debt works for me. I know plenty of people who are reckless with debt.” Fowler justified the expansion of Cunningham’s definition saying “It wasn’t his original focus, but the metaphor works across a wider context than he first realized”.
I’ve long believed that a wider context is appropriate when considering technical debt. Design decisions and code quality are far from the only sources of technical problems. Consider a hypothetical application that has zero defects and perfectly captures its domain; as the platform that hosts it ages, what would you call that if not a form of technical debt? Who, if not the architect, is best placed to be aware of and advocate for paying down these various types of debt?
Talking about technical debt is a critical step to getting it under control and keeping it under control.