My Love/Hate Relationship with “Technical Debt”

by | Mar 21, 2022

B O N C O D E   A R T I C L E

I’ve always had a hard time with the term “technical debt.” This article explores that love/hate relationship, the challenge of measuring such debt, and an alternative—albeit not new—way for measuring and managing such important software assets.

In summary: The definition of technical debt makes it hard to measure. You can’t manage what you don’t measure. Software quality is a more measurable and useful focus for software engineering excellence.

Love and Hate

I really don’t like the term “technical debt.”

There it is. I’ve said it, and I’m glad to have got this off my chest. I’ve thought that since the first time I heard the term, years ago. But then again, as an engineer who has focused on software quality for many years, I’m thankful that this marketing term helps drive many more people to think about software quality and what to do about it.

It seems there’s just as much interest in “technical debt” as “software quality,” according to Google trends.

Bear with me, and I’ll hopefully explain why I think technical debt is a useful concept but somewhat limited in its practicable application. Let’s start with its definition.

Technical Debt—Wikipedia Definition

In software development, technical debt (also known as design debt or code debt) is the implied cost of additional rework caused by choosing an easy (limited) solution now instead of using a better approach that would take longer.


Two aspects of this definition make technical debt impracticable to measure. The debt is the implied cost of additional rework.

Firstly, I take “implied” costs as future indeterminate costs. Secondly, it’s not just rework, but “extra” rework. And since all software requires rework, identifying what’s additional is difficult and not something engineering managers do in practice.

How Technical Debt Gets Incurred

When you write software, there should be a system design. But during programming, you run into an unforeseen situation that the design doesn’t cater for. There are two options:

  • Option 1: The short route—quickly cutting a corner, building something that doesn’t fit the design. But who cares? It works.
  • Option 2: The long route—which will disappoint the customer because it will take longer. But you are left with a neat system that will be more maintainable.

Option 1 leads to technical debt because you deviated from the design. It’s called “debt” because from now on, you run into this imperfection every time you want to adjust this or a related part of the system.

In the future, you, or a future colleague, will waste time understanding why this module is different from other modules that comply with the design. This extra time spent in the future is “interest” caused by the debt.

The more times you cut corners, the more future work you create, to the point that the whole system is no longer adaptable. The debt burden has become too high.

So that’s technical debt. I think that it’s a twisted metaphor, although I admit the term helps drive awareness that short-term decisions that seem at the time to be beneficial can have long-term negative consequences.

Why Technical Debt is so Fuzzy

In the real world, people who take on a debt know the consequences exactly. You borrow a specific amount for a particular purpose (for example, to buy a house) at an agreed interest rate for a specific term. The results are entirely predictable and quantifiable, thanks to specific terms and conditions and hard figures:

  • Principal (amount)
  • Interest rate
  • Term.

Which begs the question: What are the quantifiable aspects of technical debt? Based on the definition seen above, these are implied costs. So that’s euros (or hours). But I’ve never heard anyone say, “We have $1.5 million in technical debt,” whereas, in the real world, people know the size of their mortgage or car loan.

With technical debt, it’s not just the principal that’s fuzzy. How do you determine the interest rate? Is that the extra time you need for maintenance compared to a “perfect” system? What is that perfect system, and how would you ever know its maintenance effort?

I even spoke to some specialists who know a lot about technical debt and asked them, “What are the units of measurement for technical debt?”. Everyone answered the same, “There are no such units.”

Therefore, I’m not a fan of “technical debt.” Books abound saying what it is and how to prevent it. But apparently, there are no units of measurement for the term. So, more marketing fluff than something you can use to manage a software engineering function.

Not All Debt is Bad

My last lament regarding this ill-fitting metaphor is that in the real world, if you can bear the monthly repayments, and the debt is incurred for a useful purpose, debt is not a bad thing. You take out a mortgage to live in a house which you can properly value in relation to the debt.

How do you determine if you can bear the monthly costs of your technical debt in the software world? And what positives do you get in return for the liability? In some cases, it might be perfectly rational to realize a feature technically poorly but very quickly—for example, if a system is about to be retired.

How smart does it pay to be? A piece of code that is never touched again doesn’t warrant the same care as code that you will change three more times in the coming years. Moreover, who can look into the future and determine how much maintenance a piece of code will require?

From Debt to Erosion

All assets need some maintenance or renovation occasionally, or they erode. You paint your house, service your car, and a software asset is no different if you want to keep it in good shape.

I think the marketing noise generated around technical debt has helped put the problem of software erosion on the map. But it isn’t helping engineering teams manage that erosion. So, what next? How are we going to make technical debt measurable?

Let’s Talk About Quality

Quality is the degree to which something meets the
requirements you set for it.

It’s a straightforward definition that emphasizes that you need to think about the demands you place on something.

So, what requirements do you set for the structure of your software systems? And to what extent does your software comply with this? If it is possible to draft these requirements so that they are verifiable, then technical debt has suddenly become a lot more measurable.

Here are a few examples of measurable requirements you could set for software:

  • There may only be software architecture violations in X percent of cases
  • A maximum of 10 percent of code can be duplicated
  • The McCabe cyclomatic complexity should never exceed N
  • A module can never have more interfaces than X
  • A module should never be bigger than Y
  • The test code coverage should never be lower than Z.

Software teams that use these kinds of metrics have a software quality target they can measure against.

The differences (or ratio) between target and reality are easy to measure periodically, giving you actionable quality metrics. For example, you can say:

This system scores 8/10. Or this module I’m about to work on scores 4/10, so I’m going to allow extra time as more work will be needed.

Software quality (and therefore software erosion) is measurable and manageable.

Measure Quality to Understand Technical Debt

So, what does this have to do with technical debt? Well, if you periodically measure the quality, there are three possibilities:

  • Quality remains stable over time
  • Quality decreases
  • Quality increases

If your technical quality proves to be stable over time, your technical debt will not increase. You can then be confident that if the dynamics in the business remain about the same and your team remains at the right level, you will not run into problems assuming budgets stay the same.

If your quality decreases, your technical debt will increase. This means that it is becoming increasingly difficult (more expensive) to adjust your software. If the business remains as dynamic as before, you will run into problems.

The solution is the Boy Scout rule:

Always leave the camping site cleaner than you found it.
In the end, the world will be completely cleaned up.

In the software context, always leave the code better than you found it. Then the technical quality will gradually increase, and thus technical debt decreases.

And as the quality increases, you can adjust your software faster and faster, as Vopak describes in this case study.

The correlation between better quality and improved productivity may be loose, but even so, much more measurable and valuable than intangible technical debt. So, if you have a great software development team, please, give them a bonus. They deserve it!

So, my story reaches its destination—a journey from debt to awarding bonuses. From the non-measurable idea of technical debt to very tangible software quality measures.

In parting, if you’re a software manager, by all means, talk about technical debt. But measure software quality and software erosion. Your clients and your software developers will thank you.

Learn more about automated software quality assessment and monitoring.

You may be interested in this:

How Monitoring Builds Trust Between Software Teams And Managers

How Monitoring Builds Trust Between Software Teams And Managers

When business leaders need better insights into their software portfolio, they call on BonCode for independent source code analysis. For that reason, our tool-based consultancy is usually implemented as part of a top-down approach to managing software quality. It...