8 Top Metrics for Measuring Your Technical Debt

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.

Why Technical Debt Matters to Your Business

Before we dive into the details, it’s worth looking at the bigger picture.

Technical debt, or code debt, refers to any deficiencies in your code that will have to be rectified as your business grows. The more technical debt you rack up, the more rework you will need to do at a later stage.

Of course, rebuilding key systems from the ground up is inefficient. It costs time and money, on top of whatever investment you made during the original development phase.

Fixing the problems of technical debt can also be pretty demoralising for engineers — leading to reduced staff retention — and eventually, users will begin to get frustrated with your inferior product.

How Much Technical Debt Is Too Much?

This all sounds quite scary. However, technical debt doesn’t have to be a disaster.

Just as with your credit card, a modest amount of technical debt is fine. For startups, it is actually essential. Sometimes you need to launch an MVP or basic product as a proof of concept. This helps you raise money, which you can use for paying back that technical debt.

However, if you let the debt mountain grow too high, your business can end up with a massive “bill” looming over your engineering team.

The popular payment processor, Stripe, actually set out to quantify the cost of technical debt. Their research found that engineers spend 33% of their time dealing with technical debt, on average. On a worldwide scale, this adds up to a $3 trillion hit on global GDP.

Check out our technical debt calculator to estimate how much tech debt is costing your company.

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's 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.

If you’re looking for a sustainable solution for tech debt management in your engineering team, you need Stepsize. It’s the world’s first and only bespoke tech debt management tool. Track and manage issues directly from the IDE, and create issues directly linked to code. For engineers, this means no more context-switching and high-quality issues that can be prioritised based on impact and fixed. And because it integrates with Jira, your PM will love it too.

‍Learn how to get started with Stepsize here. It works with Visual Studio, VS Code, JetBrains.

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 complexity
• Class coupling
• Lines of code
• Depth 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.

Try out using Stepsize here. Track and manage actionable issues that are linked to code, directly from the IDE.

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.