How to measure technical debt

before you can plan to pay your technical debt, you will need to measure it.
In what is technical debt we discussed the basics of technical debt, in order to understand this important yet often very misunderstood concept. For most software development teams, technical debt is often associated with the cost of refactoring software to keep it working and operating smoothly.  Technical debt can also become a major hindrance and obstacle to their application modernisation efforts.
Technical debt is not something you can ignore. Leaving it within the code will lead to more interest accumulating – and it will all need paying. The uncorrected tech debts will lead to more trouble with the code, affect future software releases and scaling of the platform, cost more time and money to rectify, and even grind your operations to your halt.  The earlier you start dealing with it, the better. But before you can plan to pay your technical debt, you will need to measure it. Software developers need a simple way to quantify the debt to management.

Why measuring technical debt is important

Learning why and how to measure technical debt is very important for 2 reasons:
Technical debt can be like a taxation on the cost of operating and enhancing a software application. Teams working on a system with a high ratio of technical debt, especially if working on an application modernisation project, could spend more time on circumventing the debt than on innovation and advancing application features.
Unless an effort is made to address technical debt, it will continue to accrue at an exponential rate, which will result in teams taking longer to implement features in code, and worse code becomes more unstable and buggy.
Technical Debt Frustration
Is technical debt frustrating your application modernisation projects

Approaches to measuring technical debt

Analytical Tools

The are a number of Software Development tools like:
It involves the analysis of static code together with the kind of technical debt that you have, and the references used with the code.The tools provide estimates. For instance, with SonarQube, you will get an estimation of the hours or days it will take to fix the debt.
Internally at threenine, we also make heavy use of all Jetbrains Integrated Development Environments, specifically;
All these tools all come with code analysis and test coverage tools to assist developers in ensuring code is optimised early on.

Technical Debt Ratio Computation

The Technical Debt Ratio (TDR) is a quick approach that can be directly applied. Here, the technical debt is expressed as a ratio of the cost of fixing the software system – known as the Remediation Cost  (RC) – to the cost of developing the system – aptly called the Development Cost (DC).
				
					TDR = Remidiation Cost / Development Cost X 100
				
			
You can express these costs in terms of time. For instance, when looking at the code volume, how much time will it require to fix the software, compared to the time taken to develop it?

Calculating the Development Cost

Let’s say you’re dealing with a code file that has 100 lines of code, and it took 0.5 hours to create each line of code. This means that the total project took 50 hours – which will be the DC.
For the RC, this will be a function of the code quality metrics that is relevant to resolving the issue raised within, or it can be expressed as time, such as when it is a function of cyclomatic complexity (more on this in a moment). For now, suffice to say that it’s the answer to “How long will the team need to fix the issue?”, and this can be anything from a few hours to a couple of weeks.

Calculating the Remediation Cost

Say your software team is dealing with a project where there were 20,000 lines of code; and developing each line required 0.3hours. Then the total Development Cost [expressed in time], would be 6,000 hours. Now if fixing this code requires a remediation time of 350 hours, (which will be the RC); then the technical debt ratio will be:

Example on Technical Debt Ratio

				
					
TDR = 350 / 6000 X 100

TDR = 5.83%
				
			
You don’t want a high technical debt ratio. Usually, software teams aim to keep it under 5%. A high TDR means that the code is of poor quality.
Note that quantifying the cost is not limited to using time. More values – including the actual money spent can be applied. e.g., ratio of budget required to resolve software issues to how much it cost to develop the whole system itself. The end goal is for the development team to give the product team or management an abstract number that they can work with when planning how to handle the tech debt.

Metrics Involved When Measuring Technical Debt

The TDR is essentially a summary of multiple components. It looks at the total number of hours, days or cost needed to fix all the violated rules, compared to what it took to build the system. However, different components contribute to the tech debt, from code complexity and test coverage that looks at the total number of lines and branches that have been hit at least once by a test case, to lack of documentation, and even violations of programming rules. Let’s break down more of these:

Bugs

How many bugs need to be fixed, and how severe are they? How many are left unresolved after every iteration? The iteration is the duration in which a development cycle takes place for a completely built section or whole of the system, resulting in running-tested-software.
Comparing the number of bugs fixed, to those that remain unresolved will be key in assessing how effective the technical debt management process is. It’s also important to relate this to the severity of the bugs themselves and their impact on the system.

Duplicate code

How much of the code is copied content? This component of tech debt is expressed as a ratio of the duplicate lines, to the total number of lines in the range of code. In this case, 0% would be the ideal score, while 100% would simply mean that everything in the code has at least one instance of being copy-pasted – which is frankly absurd

Code refactoring

While the impact of code complexity on user experience is not usually as direct as bugs, it still results in tech debt that will deteriorate the performance of the system over time. This will snowball into increased maintenance requirements and software costs. Different metrics can be used when looking at the code quality, including:
This looks at how complex a source code is, based on the number of linearly independent paths in it. In simpler terms, it counts how many decisions are made in the source code. By default, each unit of code has a complexity of 1. Every branch in this code adds 1 to the code complexity, and so does every exit path. Complexity of 1 to 10 is normal, and it becomes risky as you approach 50. Anything beyond 50 is considered to be unstable.
focuses on the class hierarchy, looking at the length between a node and the root node. It answers the question, “How many classes inherit from each other, and how far back does this stretch to the base class?”
How many classes does a particular class depend on? The higher the coupling, the higher the chances of software failure.
The general principle has always been to Keep it Simple, Stupid (KISS), whether you’re designing a website, developing an app, or engineering a block of code. The more complex a code is, the more technical debt you will run into.
For these first four, the lower the number, the better it is for the code quality.
This can be measured through tools like Microsoft Visual Studio, which specifically considers the range of 20-100 to be expected, though it’s recommended that you target the higher band of 85 to 100. Here, the higher the value is, the easier the code is to understand and maintain.

Conclusion

Addressing the technical debt is a collective responsibility of the business or organisation behind it. The software developers and management need to be on board in setting measures to control it. When measuring the tech debt – such as the person-days it will need, the values obtained will bridge the gap between the tech team and decision-makers in the organisation.