How to Measure Technical Debt: Top Metrics

Editor’s note: If missed release deadlines and bottlenecks in the development and maintenance sound too familiar, chances are you have excessive technical debt. To manage it, Boris, CTO at ScienceSoft, offers metrics from our technical debt management strategy in this article. And if you’d like to know the exact reasons behind your tech debt, you can explore our offer and turn to our software development consultants.

Either when embarking on a software development journey, or being already in the middle of it, your team should stay aware of technical debt. For keeping it under control, I recommend applying the principles of visibility, importance and a gradual approach to debt removal that I’ve discussed in the article on managing technical debt. Still, to implement them, your team needs to measure technical debt first. And in this article, I’ll reveal the metrics that ScienceSoft’s project managers and technical leads use to do the estimation.

ScienceSoft’s indicators of expanding technical debt

How to understand that technical debt starts growing out of control, and there’s a need to address it right away? I recommend looking at these indicators:

• Team velocity. This metric shows how much work the team usually completes per iteration. As technical debt reduces agility, lowering velocity may mean that unpaid debt is becoming a bottleneck to the development process.
• User satisfaction rate during the process of MVP evolution. If the rate starts decreasing after previously got positive feedback (and the number of bug reports is growing), there’s a need to explicitly allocate time for debt elimination activities in the following iterations.

ScienceSoft’s advice: These metrics can be influenced by other factors too, so tracking signs of technical debt is likely to be reliable in teams you worked with for a while and know their capabilities well (to exclude such factors as unprofessionalism, lack of motivation, wrong priorities, etc.).

Stop Technical Debt from Being a Bother

ScienceSoft’s consultants can analyze your development process to reveal the root causes of tech debt and build a plan to defeat it.

Analyze my situation

ScienceSoft’s metrics to measure technical debt

• Bug count

A basic metric we use to measure technical debt is the number and severity of bugs left unfixed per agile iteration, which helps plan bug fixing activities for the next iteration.

We also compare it to the number and severity of bugs fixed per iteration to see how effectively our technical debt management strategy works. I consider it important to always correlate the number of fixed vs unfixed bugs with their severity to get an unbiased picture.

• Code to be refactored

During my practice on recovering troubled development projects, I’ve noticed that some teams don’t give proper attention to the problem of code complexity as it doesn’t impact user experience as directly as bugs. However, it creates tech debt as it leads to worse performance over time, impeded maintenance and, at last, increased software costs.

At ScienceSoft, we prevent tech debt arising from code complexity by making code quality metrics an integral part of our software development metrics system. We automatically run new code through such tools as Microsoft Visual Studio to measure the following code quality metrics:

Cyclomatic Complexity, Depth of Inheritance, Class Coupling and Lines of Code detect particular issues of code complexity, while Maintainability Index is a general metric summarizing different aspects of code quality estimation. The better their values are, the easier software is to maintain, meaning code is easy to understand, modify and reuse. Thus, if some metrics show the need for code refactoring, I suggest performing it within the current iteration or the next one at the latest.

However, constant refactoring takes out time for new features development. In the article on how to reduce technical debt, I described the principles we follow at ScienceSoft to minimize refactoring needed in the first place.

The value of measuring technical debt

I believe that measuring technical debt is the foundation of its management strategy. It will show how debt impacts the project at the current stage and help allocate reasonable time and resources on eliminating it. And to make debt estimation more precise and efficient, you need to implement automated tools and make their usage a part of your software development routine.

However, in some cases, the roots of technical debt may lie deeper than just existing bugs and complex code. This could be a poor architecture choice, weak QA strategy or lacking project management. If you want to understand the reasons behind never-ending technical debt in your project and get this problem solved or set the project right from the very beginning, you may consider requesting our software consulting services.