Measuring and monitoring technical debt

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.

Technical debt per function, with color-coded severity

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

Share:

Legal Notice

This text is the intellectual property of the author and is copyrighted by coderskitchen.com. You are welcome to reuse the thoughts from this blog post. However, the author must always be mentioned with a link to this post!

Leave a Comment

Related Posts

Int code overflow - coderskitchen
John Paliotta

Why is everything an int?

In C/C++ applications, most scalar variables are defined as ‘int’.  Do these applications deal with lots of large numbers that need 32-bit integers?  Not likely,

Improving code quality
Flavien Huynh

Software quality: To the rescue!

In this post we’ll show what a healthy relationship with code quality looks like. After our introductory post, software quality (‘SQ’ for friends) might seem

Software quality - origin story - Coderskitchen
Flavien Huynh

Software quality: Origin story

Software quality is a vast field, which has been the subject of many studies, standards and tools for a long time (if we think in