Technical debt can be quantified in various ways, but you cannot precisely quantify the associated financial debt. According to Kevlin Henney, 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.
Henney gave a keynote about Six Impossible Things at QCon London 2022 and at QCon Plus May 10-20, 2022.
There are many things about technical debt that can be quantified. Henney mentioned that we can list off and number specific issues in code and, if we take the intentional sense in which technical debt was originally introduced, we can track the decisions that we have made whose implementations need to be revisited. If we focus on unintentional debt, we can look at a variety of metrics that tell us about qualities in code.
There’s a lot that we can quantify when it comes to technical debt, but the actual associated financial debt is not one of them, as Henney explained:
The idea that we can run a static analysis over the code and come out with a monetary value that is a meaningful translation of technical debt into a financial debt is both a deep misunderstanding of the metaphor – and how metaphors work – and an impossibility.
According to Henney, quantifying how much financial debt is present in the code doesn’t work. At the very least, we need a meaningful conversion function that takes one kind of concept, e.g., "percentage of duplicate code" or "non-configurable database access", and translates it to another, e.g., euros and cents:
What is the debt value of "non-configurable database access"? What is the debt value of basing your architecture on one third-party framework versus another? What is the debt value of a decision that may (or may not) have short-term benefits but will (probably) need updating in the long-term? The question is so abstract and malleable that trying to squeeze a financial figure out of it seems not only premature, but smacks of bad science.
Henney stated that just because we may have a number for one kind of thing, such as a code metric, that doesn’t mean we can convert it to a number of another kind of thing, such as money:
It has no more meaningful correspondence to a financial value than the RGB value of my eye colour has to my height.
While we might agree that excessive code duplication represents a code smell, it doesn’t mean that duplication has a simple debt rate, as Henney explained:
In some contexts, duplication can be introduced to reduce coupling, meaning that it can reduce other debts and, therefore, it acts as a credit. Dead code can be recognised as a debt arising from obsolescence, but what about duplication in dead code? In such cases duplication is zero-rated.
Of course, we can always fabricate values and conversions, but we must recognise those as fiction rather than science, Henney concluded. It’s a little like the calculation of Blue Monday, the third Monday in January, which is allegedly the most depressing day of the year according to a "pseudoscience formula that is pure nonsense on stilts".
This article concludes the series on Henney’s Six Impossible Things keynote:
- It’s impossible to directly represent infinity or to hold infinite precision on a discrete physical computer, as storage and representations are bounded.
- Not every question has an answer; developers should increase awareness of unexpected failure modes, advertise the possibility of failure, and use time-outs to recover from waiting for an answer that will never come.
- The truth can’t always be established where it applies as not all preconditions can be checked in code due to the definitional constraints of the programming language.
- The future isn’t knowable before it happens; to deal with unknowable unknowns, a solution is to be more experimental and hypothesis-driven in our development.
- A distributed system is not knowable; failure is normal and distributed systems can provide only two of the three guarantees in consistency, availability, and partition tolerance.