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.
Method 1: Analytical Tools
The are a number of Software Development tools like:
- Upsource – Code review and project analytics
- SonarQube – Code Quality and Security
- Checkstyle – Code style and convention enforcement
- Coverity – Static Analysis
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 Rider, Webstorm, PHPStorm and Goland and these tools all come with code analysis and test coverage tools to assist developers in ensuring code is optimised early on.
Method 2: 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.
Calculating the Remediation Cost
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.
Example on Technical Debt Ratio
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:
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:
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.
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
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:
- Cyclomatic ComplexityThis 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.
- Depth of InheritanceIt 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?"
- Class Coupling How many classes does a particular class depend on? The higher the coupling, the higher the chances of software failure.
- Lines of CodeThe 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.
- Maintainability Index 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.
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.