The technical debt concept has been around for some time now. We can find it in international conferences, in scientific articles, books, and even here at Coders Kitchen.
It can be seen as the extra effort needed to fix or enhance an existing code, for which quality standards were not all respected at coding time. So the idea is that you may pay a lack of quality multiple times later.
Where do we go from this concept to actual technical debt monitoring? Is “zero technical debt” even possible?
Measuring the cost of non-quality
To monitor technical debt, we start looking at the origin, which is the lack of quality. There are many tools that detect coding rule violations in the source code; they are working with rulesets, and specialize in areas such as security, safety, maintainability, etc.
Rulesets are categorized, assigning attributes to each rule such as target, scope, family or severity.
The “remediation cost” attribute is interesting for us, as it aims to represent the average cost needed to fix a given rule. This value can be adapted to the coding language, the type of code or the development team.
Once we know how fixing a rule costs, and we have code checker tools analyzing the code and precisely locating rule violations, it is simple to compute a cumulated remediation cost for each function, file or class.
That is how we can measure the technical debt, using the cost of fixing issues found in the code.
The chart below shows the technical debt for functions shown as bubbles. The colors represents the severity of violated rules for each function.
Can the past be fixed?
In an application with many versions, there is typically legacy code, and layers of newer code with each new feature. Addressing the legacy code’s technical debt is tricky, because touching this code can have ill effects.
Of course, we can always run checkers on the legacy code and compute its remediation cost, but fixing these rule violations is not always the best solution:
- If the legacy portion of the code has stabilized with time, some rule violations might have been fixed by the iterative development
- Checking an old code with a newer ruleset can be counterproductive, as some rules might not have been part of the coding guidelines at the time
So does it mean that “If it ain’t broke don’t fix it” applies to software? Not quite.
New technical debt
Technical debt on legacy code gives us an approximation of the cost to clean the whole base code. But clearing this debt is a tricky job.
However, dealing with the technical debt we just introduced (that’s the “new” technical debt) is a clear priority and has any advantages:
- The code is fresh, and easy to understand
- Impacts are at not as deep, or at least well understood
- Coupled with the source control management, we can finely analyze the technical debt’s introduction
- As we fix, we can integrate good practices in our coding habits, and will not repeat the error
We can compute the overall technical debt, and it can produce intimidating values for sure (months or years worth of fixing!).
But the important one is the new technical debt, the one you just introduced, and can really fix efficiently.
Technical debt and technical wealth
Technical debt should not be taken at face value, because it contains several notions: issues you accumulated, and might/won’t fix, and issues you just introduced, that you should/must fix.
Some of the legacy technical debt could actually be seen as part of the actual value of the code, the technical “wealth”.
It refers to code that has stabilized, and proven that it works and performs as expected.
On the other hand, some parts of the legacy code really negatively impact the application. Addressing their technical debt requires an appropriate strategy.
As for the recent code (new, modified or relocated), monitoring its technical debt can only help maintain good quality today, and produce better legacy for tomorrow.
So it seems the financial debt analogy still stands, and it’s better to pay off technical debt early.
References
- International conference on technical debt 2020
- IEEE technical debt articles
- Technical debt books
- Technical debt in the world of Internet of Things / IoT
- Whitepaper download: Baseline Testing – The key to reducing technical debt in legacy code bases
