Rethinking Technical Debt
The metaphor is broken. It’s time to replace it.
According to the sources I have found¹, financial debt as an analogy in a software context originates from Ward Cunningham’s report from the 1992 OOPSLA conference. In it, he describes the process by which he and his team developed a financial product:
Mature sections of the program have been revised or rewritten many times providing the consolidation that is key to understanding and continued incremental development. We believe this process leads to the most appropriate product in the shortest possible time.
A bit later, he describes a risk inherent in their development process:
A little debt speeds development so long as it is paid back promptly with a rewrite. Objects make the cost of this transaction tolerable. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.
(highlighting is my own)
The “debt analogy” as Ward calls it here represent reduced efficiencies that come from “consolidation”. Although Ward is vague about what he means by consolidation, some years later he recorded a video that sheds more light on that question:
I coined “the debt metaphor” to explain the refactoring that we were doing on the WyCash product…
It was important to me that we accumulate the learnings we did about the application over time by modifying the program to look like we had known what we were doing all along and to look like it had been easy to do in SmallTalk. If we failed to make our program align with what we then understood to be the proper way to think about our financial objects then we were going to continually stumble over that disagreement and that would slow us down which is like paying interest on a loan.
To summarize: failure to re-align code to a shared mental model slows software development due to social factors, specifically “disagreement”. That disagreement, like the interest on an unpaid loan, constraints our ability to create value.
This has proven to be a very popular metaphor. So popular, in fact, that it has been co-opted to represent any number of software ills, both real and imagined. Unnecessarily complex parts of the codebase that no-one understands, early architectural choices that aren’t scaling with demand, subtle UX bugs that have never been prioritized, snippets of code that don’t meet the aesthetic values of a particularly opinionated developer; I have heard all of these system qualities and many others categorized as technical debt.
So what? A metaphor from over thirty years ago doesn’t exactly match the intentions of it’s creator. Is that something we should be concerned about? I believe so, and not because the metaphor has drifted, but because its use to represent such a wide range of situations with such a wide range of consequences has rendered it nearly meaningless, a means by which engineers rationalize work they want to do without convincing justification. In and of itself, this might not be a problem except that rather than trying to draw out the nuance of the argument, many people, particularly those who represent the business, have become tone deaf to this argument. This makes it difficult to have a coherent conversation about the cost of neglecting the state our systems and bolting another feature to the side. In the absence of those conversations, organizations struggle to balance the need to continuously deliver customer value and the need to invest in foundational technology so that value can continue to flow.
I believe the solution is to abandon the debt metaphor, not because Ward’s original thinking isn’t valuable, but because the mass appeal of the phrase and it’s subsequent corruption have rendered it unusable in a nuanced conversation. We need to do better.
Continue reading part 2: Rethinking Technical Debt: A Path Forward.
Footnotes
¹ Sources I found that discuss the origination of the term generally end up back to one of a few places: Ward’s report as written up on c2.com, Martin Fowler’s bliki post, or wikipedia’s entry, itself riddled with requests for better citation. Whether Ward was first or not might be of historical interest, but really doesn’t affect the consequence of its use today and the importance of finding a new means of expressing desirable qualities in our systems and the risks inherent in deviating from them.
