How to Measure Technical Debt

In life, there's typically more than one way to accomplish a goal. The way one person might take to reach the goal might be entirely different from the route or method another person takes to get to the same point.

This concept applies to software development, too.

However, the thing about creating software is that you can take different routes to get to the same location, and one route can still be better than the other. So, how does one find the accurate "best way" to build an effective software system? It's a major dilemma.

When a developer or team of developers takes the wrong approach to software engineering, they are incurring technical debt with or without realizing it.

In this article, we're going to break down the concept of technical debt and explain how a product owner can measure, manage, and reduce technical debt.

What Is Technical Debt?

Suppose your development teams consistently choose a more straightforward, intuitive method of software development over the advanced but more tedious options. Sure, they complete tasks with ease, but the process slowly introduces flaws in the lines of code and architecture. With every decision based on this flawed foundation, the team will slowly but surely build up a software debt, i.e., technical debtor tech debt.

Naturally, you would think that anyone would want to build a software system the right way. But the right way is often the hard way. When you're looking at using the level of code complexity for either brute-force algorithms (which are typically straightforward and intuitive) or advanced versions that aren't so intuitive, it's a lot easier to stick to the path that involves more straightforward reasoning.

Plus, consider all the external pressures to deliver something beautiful quickly. It's no surprise that an engineering team may oft for the quickest route from point A to point B without considering the cost for taking these shortcuts.

The issue is, to become a successful product owner, you have to do things right from the start. Otherwise, there's a good chance you'll have to go back and some point and make up for the laziness or lack of attention to detail.

The Source of the Problem

Technical debt may be deliberate or unintentional. Most software engineering teams are somewhat aware that it's building as they go.

Just as with financial debt, technical debt incurs interest. The longer you go without fixing it, the worse the problem gets. Why? Due to the way software coding works, you often have to create additional bad code to fix the original bad code. Eventually, you'll need more poorly-written code to try to manage the growing mess.

Accidental technical debt may be the result of latent issues that predate the existing team. One example of this is outdated software. As software standards continue to get higher and maintenance costs to grow, it's easier to get left behind without even realizing it.

The Costs of Technical Debt

Once you start getting lazy with your code, it's hard to stop. As new features get added to the software down the line, developers will add more bad code. Eventually, the original commitments to create something clean and effective are out the window, and standards get diminished. The truth of the matter is that maintenance for bad code gets more complicated, so you're only making things worse for yourself and your team.

The "shortcut" route to the finish line comes with its own set of consequences. The various types of technical debt can create issues related to productivity, code complexity, test coverage, lines of code. Not to mention, you also have to factor in the maintenance costs of having your development teams either waste time working around issues in the software system or overhauling it altogether when it becomes too hard to manage technical debt.

Measure Technical Debt: The Technical Debt Ratio

The best way to avoid these issues and the costs for your software development is to measure technical debt and then work out solutions to manage it.

First, there are tons of variables that you have to consider when trying to calculate technical debt. There's cyclomatic complexity, lines of code, depth of inheritance, nesting depth, afferent/efferent couplings, and much more.

As a rule of thumb, the simplest solution is to express the issue as a ratio. The technical debt ratio measures the difference between the cost to fix the software and the cost to develop it.

Technical Debt Ratio = (Remediation Cost divided by Development Cost) x 100

Ideally, you want a low technical debt ratio of 5% or lower. If it's higher, it reflects low-quality software.

Let's apply this analysis to one business case. Suppose you want to turn your Remediation Cost (RC) into a function of any quality metric that your software development team thinks is the most relevant based on code issue resolution rules. You could make it a function of cyclomatic complexity, which would describe how long it takes to fix code function issues. RC, then, becomes directly proportional to the complexity of that code function. Once you've figured that out, you can determine how much time it will take to fix the entire issue.

You can use this same concept and apply it to other code quality metrics and measure and manage technical debt in other ways as well.

Reducing and Managing Technical Debt

The best way to reduce technical debt is to regularly manage it and not let it fall to the wayside. It's easy to put the blinders on until you get to the finish line, but the technical debt will keep pushing the actual finish line further and further away the longer you avoid it.

As you build out your software, consider achieving regular test coverage with automation to mitigate the accumulation of tech debt. Revisiting this formula expressed as a ratio again and again as you develop will save you hours of work and lots of money down the road in exchange for a much smaller amount of work now. When it comes to software engineering, it's always worth it to do things the right way.