Hitchhiker's Guide to Software Architecture and Everything Else - by Michael Stal

Thursday, March 05, 2015

Technical Debt - The Downside of Metaphors

The term "debt" is a metaphor from economy. Its use for software development seems to be very reasonable. Whenever developers fail to address quality issues in their software, they will have to pay this debt back. That is quite simple, isn't it?

However, we can easily find weaknesses of the term "technical debt":

When a system reaches its end of lifecycle, all debt will be gone. Try this for financial debt.

Financial debt is a separate entity, i.e. two debts do not intertwine, while software debt sometimes can't be easily located, isolated or separated, because it is woven into the system.

Technical debt may stay unpaid, if software engineering comes to the conclusion that the cost for refactoring would be higher than keeping the debt untouched.

Financial debt is created intentionally. This is certainly true for some technical debt issues as well such as temporary workarounds. However, many kinds of technical debt are accidental without architects even recognizing it.

Technical debt is destructive. If possible, you would like all of it to be eliminated. In contrast, financial debt often is more constructive - such as increased cash flow.

Financial debt is independent of other system parts, while technical dept in one place can be affected by other parts, and vice versa. An example would be modification of the system that makes the code parts containing the technical debt obsolete.

Interest rates are mostly determined by banks and usually stay fixed over the specified time. In the context of design debt the interest rates increase the longer the debt is not treated. The pay back time is usually not predetermined. And the same kind of debt may be more expensive to pay back in one system part than in other parts.

While almost all forms of financial debt are paid back continuously until the debt plus the interest rates are fully covered, each single technical debt in most cases must be paid back at once.

There is one kind of debt in the financial domain, while technical debt has many different shapes.

If you think about it, you'll find other metaphors that are more convincing. For example, a tumor or infection has many similarities with what we call technical debt: It can occur accidentally, or intentionally if you don't take care of your health. It must be paid back at once - you are either ill or not, which isn't quite true in practice, but very close. The longer it is not treated, the worse the health condition will become - think of viruses that spread and damage other organs. Infections and technical debt are mostly destructive. Both can be monitored in imaging devices or labor diagnostics. There are tumors that are difficult to get rid of and that cause severe damage, while others are harmless if treated early. The worst ones can even become lethal. So my first guess would be to call it software infection instead of software debt.

Another possibility is to use environmental pollution as a metaphor. Like technical debt it may occur incidentally or (most of the time) accidentally. You must pay it back, but you can do this part by part. If left untreated, the situation worsens. It is purely destructive. Often, it can't be easily separated from the environment. Thus, another possibility would be to call it software pollution. Software Architecture Sustainability is a metaphor that is related to environmental issues. And so is the term "Software Ecosystem".

Other metaphors could be considered as well such as terms for similar issues in hardware or building architecture (consider design erosion).

My personal favourite is Software Infection (respectively technical infection, code infection, design infection). Of course, this metaphor has its own liabilities, but it is much closer to its cousin in software development than the debt metaphor is.

And it sounds appropriate to speak about a sick component or architecture. Or to visualize an infection using a modality like in medicine.

I know that it is too late to get rid of the expression "technical debt", but at least we should handle it with care. Some metaphors that sound good in the beginning may turn out to be not well aligned with what we like to visualize.



  • I liked the head first design patterns which dates back to the 2004. Now 10 years later, I'm wondering if there are newer, updated references that I should get my hands on.

    Welcome back btw.

    By Blogger Unknown, at 11:31 AM  

  • You say
    "When a system reaches its end of lifecycle, all debt will be gone. Try this for financial debt."

    That is no problem. If you have enough debt in a company and some cash inflows are dropped, the company is bankrupt. The assets of the company will be used to pay a part of its debt, but usually an amout of debt will stay unpaid.

    So, from an economical point of view, the term technical debt is absolutely correct.

    The problem is, that either financial nor technical debt forces the debtor to pay it back.

    Best regards!

    By Blogger Gerrit Beine, at 4:14 PM  

  • Gerrit, I am not convinced that your example of bankrupt companies is applicable to software engineering. What and to whom would you sell assets if you got a "bankrupt" software system? The components of a badly designed software? And to whom would you pay the debt back? You are a creditor and a debitor at the same time.
    In software engineering debt mostly is part of the product itself. Financial debt is not part of a product. The assets used to pay debt back in the real world might also be manufacturing equipment, or debt from 3rd parties.

    By Blogger Michael, at 6:32 PM  

  • Very helpful information

    By Anonymous UIG, at 8:35 PM  

Post a Comment

<< Home