What Technical Debt Is And How It’s Measured

Daniel Okwufulueze
Feb 20, 2019 · 7 min read
Too busy for efficiency. This image has been modified by me. Source: https://pbs.twimg.com/media/DTvOdk9VMAAwBQ5.png

There’s this saying that there’s more than one way to crack an egg. This concept applies to software engineering too. In engineering a software system, there’ll be more than one way to do it. This poses a challenge: finding the best way.

The Dilemma

It would seem that the best and most efficient ways of building software systems aren’t usually the most obvious and intuitive. A look at the computational complexities of brute-force algorithms [mostly intuitive, straightforward, obvious, and easy] vs their advanced but efficient counterparts [not so obvious and intuitive] should show this.

It’s easier and feels quite natural to reason about very simple solutions than advanced ones. Add to this the need to deliver features fast, and an engineering team may find itself choosing a quick and easy way over a time-taking, advanced, but better approach that would save everyone unnecessary maintenance costs in the future.

Team Decides: Let’s Move On Guys, We’ll Revisit This Later

To decide to go the inefficient, fast and easy way, a team may reason that at some future point, work will be done to cater for this “little” inefficiency: “We just need to move fast at the moment” becomes the mantra on everyone’s lips. It’s soon discovered that the moment where everyone must move fast never goes away and that the only way to move at all times, is fast. Time to fix accumulated software issues will always appear to encroach on the time to build new features. The thinking will always be:

We could be building some really cool new features right now.

We’ll come back to this later when we have the time.

Software Entropy increases due to the tendency of software to become difficult and expensive to maintain as it gets modified over time.

It doesn’t get easier over time to maintain software. Maintenance tends to cost the same at best, or gets more difficult and costlier, especially as the codebase expands.

Technical Debt [deliberate] is the cost incurred when poor design and/or implementation decisions are taken for the sake of moving fast in the short-term instead of a better approach that would take longer but preserves the efficiency, maintainability, and sanity of the codebase.

The example used above applies to technical debt incurred deliberately. It’s possible to incur technical debt inadvertently. One very easy way an engineering team can suddenly find itself dealing with a technical debt problem is if their technology gets outdated. With software standards rising ever higher comes obsoleteness of legacy software and attendant technical debt on dependencies.

Numbers Please — How Do We Measure Technical Debt?

How do we assign numbers to this Technical Debt concept? Source: https://static.wixstatic.com/media/279667_7ef75f79ddad467f964792939632dd79~mv2.jpg

It doesn’t help decision-making if we can’t place a number on such an important concept. Once we can quantify it, we can make analytical comparisons, we can know if we’re making progress, we can plan with data. Non-technical team members can get an understanding of the quality of the software upon which the business runs.

But so many variables are involved in determining code quality, of which technical debt computation is an important factor. Some of these variables include complexities [cyclomatic and cognitive], lines of code, arity, maintainability index, Halstead Complexity Measures, depth of inheritance, afferent and efferent couplings, nesting depth, time to write n lines, etc. With so many metrics to consider, it appears difficult to know how much work we need to do to pay off technical debt.
It turns out, however, that there’s a simple solution to this problem — it lies in how we choose to express the problem:

Express technical debt computation as a ratio. A ratio of the cost to fix a software system [Remediation Cost] to the cost of developing it [Development Cost]. This ratio is called the Technical Debt Ratio [TDR]:

Technical Debt Ratio = (Remediation Cost / Development Cost) x 100%

Really simple isn’t it! Technical Debt Ratio [TDR] is simply the ratio of remediation cost to development cost.

Generally, no one wants a high Technical Debt Ratio [TDR], some teams favour values less than or equal to 5%. High TDR scores reflect software that’s in a really poor state of quality.
If both remediation and development costs are represented in time [hours], for example, TDR scores simply indicate how long it would take an engineering team to restore sanity to their codebase and achieve quality. So smaller TDR values are to be preferred at all times.

Prefer smaller TDR values at all times

RC α Cyclomatic Complexity
RC = k(Cyclomatic Complexity)
k is a constant

Once k and Cyclomatic Complexity above are given, RC can be easily computed.

Development cost [DC] can be imagined as the cost of writing some lines of code [the time it took to write that much line]. For example, if a file has 100 Lines Of Code [LOC], and it takes an average of 0.27 hours to write one line, that is, Cost Per Line — CPL, is 0.27 hours, the development cost [DC] would be:

0.27 hours/line x 100 lines = 27 hours.

This means it took 27 hours to develop the code in that file.

Now that we have all the relevant variables for TDR covered with their associated abbreviations, let’s remind ourselves of the abbreviations again:

Development Cost: DC [hours]
Lines Of Code: LOC [lines]
Cost Per Line: CPL [hours]
Remediation Cost: RC [hours]
Technical Debt Ratio: TDR

So, referring back to the definition of the TDR, we can write:

TDR = ( RC / DC ) x 100%



Let’s treat an example codebase where the remediation time is 365.8 hours; lines of code is 26,398 lines; cost per line is 0.27 hours/line.


RC = 365.8 hours
LOC = 26,398 lines
CPL = 0.27 hours/line
Recall that DC = CPL x LOC
=> DC = 0.27 hours/line x 26,398 lines
DC = 7,125.83 hours
TDR = ( RC / DC ) x 100%
TDR = ( 365.8 hours / 7,125.83 hours ) x 100%
TDR = 5.1%

Technical Debt Ratio for this example codebase is 5.1%


For a quick recap, technical debt is the cost incurred when engineers try to cut corners by choosing a fast and easy way over an advanced and efficient but time-consuming way when building software. Technical debt accumulates interests over time and increases software entropy. To effectively measure technical debt, we need to express it as a ratio of the cost it takes to fix the software system to the cost it took to build the system. This quantity is called the Technical Debt Ratio [TDR].

I hope you enjoyed reading. Please let me know what you think, especially if I missed anything that could help further clarify this really important software metric.

The Andela Way

A pool of thoughts from the brilliant people at Andela

Daniel Okwufulueze

Written by

Husband; Dad; Technology Leader & Mentor; Blockchain Enthusiast & Developer; Agnostic. For pastime, I read, write, swim, play musical instruments, think.

The Andela Way

A pool of thoughts from the brilliant people at Andela

Daniel Okwufulueze

Written by

Husband; Dad; Technology Leader & Mentor; Blockchain Enthusiast & Developer; Agnostic. For pastime, I read, write, swim, play musical instruments, think.

The Andela Way

A pool of thoughts from the brilliant people at Andela

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store