Much like running up bills on your credit card, technical debt can easily . To avoid this happening, you need to keep track of how much debt you’re building up. get out of hand 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 . You can track it in your issue tracker but the easiest way to do it is to use or 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. resolved vs unresolved issues you have Stepsize VSCode 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. is an aggregation of several metrics that of your code: Code quality quantify the overall quality and complexity 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 is a metric that counts the number of times a particular line has seen code deleted and replaced, or rewritten. Code churn 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 metric looks at the same issue from the opposite direction. code coverage 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. . Higher than this is to be commended, while a lower score indicates work to be done. A good target number here is 80% 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 . If you get too many people working on the same tasks, you can easily end up with a steaming pile of cruft. software engineering 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 engineers have contributed to each project — this is your . how many 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, can be calculated as a function of the code quality metrics mentioned above. remediation 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. Development cost 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. . If you get to multiples of this figure, it’s long past time to start tackling your technical debt! In an ideal world, your TDR would be around 5% Bonus: Front-End Response Time The isn’t strictly about technical debt. However, this metric can act like a warning light. responsiveness of your front-end 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 or editor extensions are totally free and will help you track your technical debt and measure your progress. Stepsize VSCode JetBrains 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, is a tool with a narrow focus. SonarQube 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 is as the system profiler of your product. This tool assesses the quality of your code and delivers the information through visualisations. Teamscale Teamscale can handle multiple metrics, with the option to configure custom dashboards. The platform also offers some quality management features, although it lacks the and detailed technical debt analysis provided by Stepsize. annotated issue tracking 4. Velocity by Code Climate Billed as an “engineering intelligence” platform, is primarily designed to help managers to improve workflows and assign resources. It is not specifically designed for , but there is some crossover. Velocity by Code Climate handling technical debt 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, 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. Jira Conclusion As we have discovered, there are many different ways to measure and . If you are looking for , Stepsize should definitely be on your shortlist. manage technical debt an all-in-one solution Our platform is , and powerful enough for managers to gain valuable insights — from visualising code debt in dashboards to assessing the future impact on your roadmap. intuitive for engineers 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