From Wikipedia, we can discover a brief explanation of technical debt:
Technical debt (also known as design debt[1] or code debt) is "a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution".[2]Technical debt can be compared to monetary debt.[3] If technical debt is not repaid, it can accumulate 'interest', making it harder to implement changes later on. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward. On the other hand, some experts claim that the "technical debt" metaphor tends to minimize the impact, which results in insufficient prioritization of the necessary work to correct it.[4][5]
In theory, dealing with technical debt is very promising for improving software quality, but in practice it's not easy to use this measure. Indeed, the big challenge is how to evaluate the technical debt.
Many tools provide their own algorithms to evaluate it depending on many factors:
- Issues detected by the static analysis tools.
- Code coverage.
- Code duplication.
- Documentation.
- Lack of design.
And whatever the tool or the method used to evaluate it, it must be very flexible and easy to customize. The company must have the possibility to calibrate its algorithm depending on its context.
Agile algorithm
There are two options to make the debt calculation flexible:
- Define a specific algorithm and give the possibility to change its parameters depending on the development team's context.
- Don't define a specific algorithm, and give the user a way to customize the calculation formulas.
With CppDepend, we chose to make the algorithm very flexible, and it can be changed for each rule depending on the project context.
For example here's a formula for the debt introduced by too big types:
And here's another formula for a Cppcheck issue.
This way, each team can configure their debt calculation depending on the project context, and they have the possibility to reduce the estimation errors of the debt calculation.
The comparison with a baseline
It's very difficult to evaluate technical debt. Each algorithm used will introduce many estimation errors, and we don't have much time to calibrate it, since it depends on many factors.
However, if we compare the technical debt of two iterations of a codebase, we can have a good idea about the evolution of its code quality.
The difference between the debt metrics of two versions minimizes the estimation errors and gives a more accurate debt metric.
Conclusion:
The technical debt metric is a powerful way to control the code base quality. However, the user must have an easy way to calibrate it and reduce the estimation errors. And it's more interesting to rely on the technical debt evolution than on the debt itself.