BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Technical Debt is Quantifiable as Financial Debt: an Impossible Thing for Developers

Technical Debt is Quantifiable as Financial Debt: an Impossible Thing for Developers

Lire ce contenu en français

Bookmarks

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:

  1. It’s impossible to directly represent infinity or to hold infinite precision on a discrete physical computer, as storage and representations are bounded.
  2. 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.
  3. 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.
  4. 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.
  5. 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.

About the Author

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Doesn't have to be scientific

    by Erwin Glassée,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Henney is probably right about there not being a scientific method, and the understanding of the metaphore- although some of the examples can be solved with overly complicated valuation techniques.

    But it doesn't have to be scientific for the economy to do this every day. If the company purely exists of this software and it's quoted on the stock exchange, the financial debt equals the difference between similar company values without technical debt in their software and the actual company value.

    Whether there's a point to computing that financial debt, is an entirely different debate.

  • Re: Doesn't have to be scientific

    by Kevlin Henney,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The financial debts of a company are its obligation to pay one or more parties certain amounts of money. These constitute its liabilities. The quoted value of a company on the stock exchange is a market-based estimation of desirability at a point in time based on confidence and other social factors. Although such a value may be influenced by knowledge of a company's assets and liabilities, you cannot derive market value from a company's assets and liabilities and, importantly, the converse is also true: you cannot derive financial debt from the market value. In other words, looking at different company valuations tells you nothing about their debts, real or imagined.

    The idea that companies can be so similar that the only difference between their market valuation can be attributed to their technical debt is an interesting thought experiment but, sadly, it can be nothing more. For such a scenario to exist in the real world, not only would you have to ensure a number of things were very similar (almost identical companies, with equivalent operations and strategies, near identical workforce, operating in the same market, etc.), you would also have to eliminate differences of probability given that we know a large contributor of success and failure is down to luck (good and bad), otherwise you would largely be measuring natural sample variation. This seems to qualify as another impossible thing 🙃

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT