By Stephen, Head of Forecasting Engineering

Tech debt has become a catch-all cliché – vague, overused and often misleading. It’s time we move on.

Everyone involved in software engineering has at some point used the phrase tech debt. It has become ubiquitous; seldom does a roadmap meeting, tech blog or report avoid its reach.

The phrase started out as a metaphor for quick and dirty code but its over use, over time, to describe a multitude of real world circumstances, has made it near impossible to identify its intended meaning.

What’s the upshot of this? It renders the use of tech debt as a phrase increasingly problematic. 

The problem is, it’s difficult to be sure. Tech debt has become a catch all phrase and I’ve seen it used to describe everything from design debt and inadequate test coverage to large, monolithic interdependencies.

And therein lies the problem; two people cannot have a useful conversation about tech debt because it means so many things.

Furthermore, the huge spread of possible causes makes it actively unhelpful in making decisions around where to improve a code base because it doesn’t give space to describe value.

It’s like saying things could be better. Of course they could — that’s axiomatic — but it doesn’t help you decide what to improve or how.

Its inability to describe value is its Achilles’ heel. Taking the original intent of the metaphor – and it can be a useful metaphor, but remember, it’s just a metaphor – the debt one pays is dependent on each very specific context, and that context shifts over time, causing the debt profile to change:

• Doing nothing might cause what was heavy debt to reduce, or vice versa
• Underlying hardware or operating systems could change
• The relative business value of the debt might change
• Customer usage might change

Thus, saying “we need to reduce tech debt” is giving no insight into value or return on investment.

Instead, when teams are saying this, we should ask a more specific question; “what is the improvement to be made and how does it make the cost profile and overall business value better?” Even better yet, that question should have an answer that is more measurable than “less tech debt” and allow a better view of what a successful outcome can be.

At G-Research, we’re getting into the habit of asking better questions and focusing on what needs to improve and what’s the cost payoff of that improvement.

Depending on your role, your business or industry, you may have a slightly different approach and set of measurements but the same applies – focus on the key things that impact your flow and your value delivery.

For example, the questions you ask could be related to time to release a bug fix, quality or reliability of running instances, cost to add new features, complexity or time to get new joiners up to speed with the code base. Regardless of what they are, keep talking about them, be specific and avoid plumping for the generic tech debt.

Keep using tech debt and you risk asking the wrong questions – and solving the wrong problems.

TLDR; Stop saying tech debt – be more precise.