How to Measure Your Technical Debt: 8 Metrics to Consider

Much like running up bills on your credit card, technical debt can easily get out of hand. To avoid this happening, you need to keep track of how much debt you’re building up. 

Technical debt metrics are designed to help you make sense of all the data you collect. There are many different metrics to choose from nowadays, and plenty of tools for recording the data.

In this post, we’re going to look at how they work, and help you to choose the right metrics for your business.

8 Metrics for Measuring Your Technical Debt

The main reason why technical debt is so common is that many businesses don’t even realise how much they have. It’s only when a company wants to add new functionality that the problems emerge.

To ensure you don’t fall into the same trap, it’s a good idea to set up some technical debt metrics.

Notice we say “metrics” in the plural. There is no single data point that will give you an exact understanding of your technical debt. Instead, you will need to build a picture using a collection of metrics.

So, which ones should you be prioritising? Here are some of our favourites.

1. New Bugs vs. Closed Bugs

Here’s a nice easy one to start.

Every known bug is essentially a tiny sliver of technical debt. If you want to know your total debt, it’s important for your engineers to keep a tally.

Assuming your engineers make a note of when bugs are fixed, you can calculate how effectively you are managing your technical debt. If new bugs are outnumbering closed bugs, you need to make some changes.

2. Debt Index

Debt index is based on a ratio of resolved issues to total issues, where higher priority issues weigh more heavily.

If your engineering team is tracking and prioritising codebase issues on a regular basis, you can easily see how many resolved vs unresolved issues you have. You can track it in your issue tracker but the easiest way to do it is to use Stepsize VSCode or JetBrains editor extensions that allow you to track and prioritise codebase issues directly from your editor. Moreover, you’ll be able to see the progress on a dashboard that’ll motivate your team to fix even more technical debt.

3. Code Quality

Complex code is a sure sign of growing technical debt. At some point, someone is going to have to unravel that mess.

Code quality is an aggregation of several metrics that quantify the overall quality and complexity of your code:

Cyclomatic complexityClass couplingLines of codeDepth of inheritance.

With each of these individual metrics, you’re aiming for the lowest possible score. The same goes for the overall metric of code quality. 

4. Cycle Time

Another metric that is closely linked to code quality is cycle time.

In technical terms, this measures the amount of time that passes between the first commit, and deployment. But when you’re measuring technical debt, you need to study the time it takes to make changes to existing code and to solve problems without using quick fixes.

If your engineers are spending hours fixing small bugs, you know that there is some technical debt lurking in your code.

5. Code Churn

Code churn is a metric that counts the number of times a particular line has seen code deleted and replaced, or rewritten. 

When you are developing a new feature or working on a particular section of your product, some churn is inevitable. But after you have launched a new version and fixed the standout bugs, code churn should start to diminish quite rapidly.

If you see high churn in any area of your code over a longer period of time, it probably means that mistakes or quick fixes are being made with each iteration.

6. Code Coverage 

In a sense, the code coverage metric looks at the same issue from the opposite direction.

In this case, you are measuring how much of your code is executed when you run your testing suite. This gives you an indication of how efficiently your code has been written — the more lines that are unused, the more likely it is that you have poorly written code.

A good target number here is 80%. Higher than this is to be commended, while a lower score indicates work to be done.

7. Code Ownership

In the culinary world, it’s often said that “too many cooks spoil the broth”.

The same idea can be applied to software engineering. If you get too many people working on the same tasks, you can easily end up with a steaming pile of cruft. 

That said, you don’t want only one engineer taking ownership of any entire project. If they get sick or leave your organisation, it’s game over.

For this reason, it’s a good idea to analyse who has worked on which projects. As part of the process, you should count how many engineers have contributed to each project — this is your code coverage.

The average figure will reveal whether you have an efficient system for delegating tasks, or a free-for-all. The ideal situation is to have one complete team taking charge of each project.

8. Technical Debt Ratio (TDR)

As the name implies, this metric was designed specifically for calculating the overall future cost of technical debt. This can be in terms of time, or some other resource.

The equation is relatively simple:

(Remediation Cost ÷ Development Cost) × 100 = TDR

In this case, remediation cost can be calculated as a function of the code quality metrics mentioned above. 

Development cost is a simple calculation of the number of lines of code required to build a product or feature, divided by the average resources expended per line.

Put the two together in your TDR equation, and you end up with a simple ratio that tells you how much time or how many resources you will need to spend on fixing problems. 

In an ideal world, your TDR would be around 5%. If you get to multiples of this figure, it’s long past time to start tackling your technical debt!

Bonus: Front-End Response Time

The responsiveness of your front-end isn’t strictly about technical debt. However, this metric can act like a warning light. 

If your front-end takes a long time to load, it is generally because you have over-complicated code or outdated technology. Both are important forms of technical debt.

The Best Tools for Measuring Technical Debt

Hopefully by now, you should be starting to get an idea of what you need to measure in order to manage your technical debt. All that remains is to decide which tools to use for the task.

Here are some of the standout options that will suit most projects:

1. Stepsize

Specifically designed for codebase issue tracking, Stepsize helps you identify and highlight problems right inside your favourite editor.

The Stepsize VSCode or JetBrains editor extensions are totally free and will help you track your technical debt and measure your progress.

Because Stepsize integrates with Jira, Asana, Linear, Azure DevOps, and more, you can adopt this app without radically changing your workflow. 

• Create & view code issues directly from your editor
• Track & prioritise code improvements like technical debt
• Add key issues to your sprints with issue trackers integrations

2. SonarQube

Rather than a complete solution for tracking technical debt, SonarQube is a tool with a narrow focus.

The main purpose of this platform is measuring and improving code quality. SonarQube highlights bugs and messy code through automatic analysis, delivering numbers and grades that you can track over time. 

3. Teamscale

The best way to describe Teamscale is as the system profiler of your product. This tool assesses the quality of your code and delivers the information through visualisations.

Teamscale can handle multiple metrics, with the option to configure custom dashboards. The platform also offers some quality management features, although it lacks the annotated issue tracking and detailed technical debt analysis provided by Stepsize.

4. Velocity by Code Climate

Billed as an “engineering intelligence” platform, Velocity by Code Climate is primarily designed to help managers to improve workflows and assign resources. It is not specifically designed for handling technical debt, but there is some crossover. 

Velocity pulls data from Jira and other DevOps tools to offer insights. You can also run automatic code analysis, and gather information through inline issue reporting. 

5. Jira

One way to measure technical debt is by creating and monitoring the backlog within your chosen project management workflow. 

If this is the approach you want to take, Jira is an obvious option. It doesn’t provide any of the code analysis features of the apps mentioned above, but it’s a good platform for managing tasks.

Conclusion

As we have discovered, there are many different ways to measure and manage technical debt. If you are looking for an all-in-one solution, Stepsize should definitely be on your shortlist.

Our platform is intuitive for engineers, and powerful enough for managers to gain valuable insights — from visualising code debt in dashboards to assessing the future impact on your roadmap.

Remember that all high-growth software companies invariably take on technical debt. But it’s important to measure it and consistently clean up your code to allow your company to keep growing.

Also published on: https://www.stepsize.com/blog/8-top-metrics-for-measuring-your-technical-debt