With technical debt, we end up paying a gradually rising cost. The technical debt metaphor was intended as a way to help us talk and think about the invisibility of decisions and qualities in code.
Kevlin Henney gave a keynote about Six Impossible Things at QCon London 2022 and at QCon Plus May 10-20, 2022. His sixth impossibility was Technical Debt is Quantifiable as Financial Debt:
We can quantify things like how many debt items we have, the estimated time to fix each debt item, a variety of metrics associated with our code, such as cyclomatic complexity, degree of duplication, number of lines of code, etc. All of these are identifiable and countable, but quantifying how much financial debt is present in the code doesn’t work.
A metaphor provides us with a vocabulary and a model of reasoning for something that may be abstract and elusive, Henney said. Metaphors are not direct equivalences or identities, and treating them literally normally misses the point.
Some decisions are taken deliberately and with the idea that we gain a short-term advantage by choosing, say, a less general solution so that we can either release sooner or get more experience with a feature, Henney said. However, if we don’t replace or improve that solution as we accommodate changes that demand greater generality, the original design will hold us back. We will end up paying a gradually rising cost for not choosing a better design. This was the original intent of Ward Cunningham’s debt metaphor, Henney mentioned.
We can also incur debt unintentionally, as Henney explained:
For example, letting poor code quality proliferate unchecked in our codebase through technical neglect. This is the common sense in which the term "technical debt" is used, to the point that many people see poor code as a synonym for technical debt. That is an unfortunate simplification as it misunderstands how financial debt works and, therefore, one of the lessons of the metaphor. Having debt is not necessarily a problem and it does not necessarily arise from neglect, but having unmanaged debt that is accidentally accumulated and left unchecked is a problem.
InfoQ interviewed Kevlin Henney about communicating technical debt.
InfoQ: You stated that technical debt = the cost of owning the debt. Can you elaborate how this works?
Kevlin Henney: In talking about technical debt, a number of teams successfully avoid the pitfalls of trying to convert simple code metrics into a currency value. They instead get caught by a different fallacy. A team might go through their code and estimate the amount of effort involved in addressing different debt items. This estimate might be counted in hours, but this may then – by the often assumed axiom of time is money – converted into a financial figure.
There are two subtleties we should be clear about. The first is that what is calculated is an estimate of the cost and not the actual cost. We should always be clear about distinguishing estimates from actuals.
The second subtlety cuts to the heart of what the technical debt metaphor is all about. In calculating the estimated cost needed to address the debt, there is an implicit assumption that the technical debt is the cost of repaying the debt. The point of the debt metaphor, however, is that a debt incurs costs for as long as you have it and that, over its lifetime, the total cost of ownership will be greater than the cost of repaying it at any point in time except its inception. Technical debt relates to the extra work that has been added in the past, the present and the future by having the debt, not simply the cost of repaying the current balance. That’s the message of the metaphor.
InfoQ: What’s your advice for using the technical debt metaphor properly?
Henney: When most developers say "technical debt" they actually mean "unmanaged technical debt". It is worth maintaining this distinction in conversation.
We should also remember that the metaphor was intended to enable communication. That means that even when we respect the metaphor, it won’t always be the best way to talk about decisions and code quality. We may find other metaphors are more useful.
So, we should certainly try to use the concept of "technical debt" more accurately, but we shouldn’t get hung up on it as a foundational concept. As Émile-Auguste Chartier observed, "nothing is more dangerous than an idea when you have only one idea."