The term technical debt is often used to explain the nature of software quality and quality decay: the option to decide for reduced quality (taking debt) in exchange for more features or faster time-to-market, the fact that some quality issues will hit you hard later on (interest), or the problem that accumulation of too many quality issues might make further development of a software system impossible (just as too much debt might break a company). Still, we try to avoid the actual term technical debt, both in our own tools and when dealing with our customers. Our main reason is that the metaphor is often overdone and its users tend to see too many parallels to its financial counterpart.

Technical debt can never be measured precisely

Financial debt is easily expressed in exact numbers; just check your bank account. Technical debt has a lot of fuzziness associated with it, both in the amount of debt (how »expensive« is a code clone, a god class, or an architectural flaw?) and the cost of repaying it (developer efficiency varies a lot, the complexity of a refactoring depends not only on the type of issue, but also on the context). Using the term debt, practitioners often assume an amount of precision that just does not exist. This is further promoted by some analysis tools that report a single exact number for the technical debt.

Technical debt should not be expressed in terms of money

The term technical debt is often interpreted as a way to describe quality issues in terms of money. Some approaches and tools even calculate a dollar amount for technical debt. However, it is very dangerous to compare this amount with others, such as the estimated redevelopment cost of a system. While this might seem like an easy decision—just compare two dollar values—the actual rebuild vs. refactor decision has a lot more facets.

Technical debt not always has to be repaid

In financial debt, we usually expect to pay the debt eventually. As such, the debt is something to plan for in the future. In technical debt, you might get away without paying anything at all. In fact, sometimes (e.g. by removing no longer needed features) parts of the technical debt just disappear without real effort.

Interest in technical debt is not uniform

In financial debt, you agree on an interest rate and can plan, quite precisely, the amount of money you have to pay in a couple of years. This is not true for quality issues. Many are local and can be fixed or ignored easily, while a few will hit you very hard. But most of the time, you do not know which are the bad ones. While on average, it might work to assume a fixed interest rate, the variability is pretty high.

You never get a complete view on technical debt

As stated before, as long as your accounting is in order, you can easily get an overview of your financial debt. In technical debt, many practitioners limit their view to a single aspect, such as code smells or »issues that are detected by a certain analysis tool«. Even combining several tools and expert knowledge, it is very likely that you will miss some issues. The risk here is to assume that this view captures all of your debt and hence you focus too much on these issues, ignoring other problems completely.

Should we drop the metaphor?

While I see many risks in using the metaphor too freely, it is also a good tool for discussing certain characteristics of software quality. However, I strongly advise to use the term technical debt carefully and always keep in mind that this is only a metaphor. Thus, drawing parallels to financial debt can be misleading and should always be checked carefully.