Form wikipedia we can discover a brief explanation about the 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 it’s very promising to deal with the technical debt to improve the 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 provides their 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 of 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 context.
- Not define a specific algorithm and give to the user a way to customize its calculation formulas.
With CppDepend we choose to make the algorithm very flexible and it could be changed for each rule depending of 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 could 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 the technical debt, each algorithm used will introduces many estimation errors and we do not have much time to calibrate it, 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 will minimize the estimation errors and give 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 the debt itself.