Wikipedia provides a concise 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 for evaluating it based on several factors:
- Issues detected by the static analysis tools.
- Code coverage.
- Code duplication.
- Documentation.
- Lack of design.
Whatever tool or method is used to evaluate technical debt, the calculation must be flexible and easy to customize. Each organization should be able to calibrate the algorithm according to its own context.
An Agile Algorithm
There are two ways to make the debt calculation flexible:
- Define a specific algorithm and allow its parameters to be adjusted according to the development team's context.
- Do not define a fixed algorithm; instead, give users 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 is a formula for the debt introduced by types that are too large:
And here is another formula for a Cppcheck issue:
This way, each team can configure its debt calculation according to the project context and reduce estimation errors.
Comparison with a Baseline
Evaluating technical debt accurately is difficult. Every algorithm introduces some estimation error, and thoroughly calibrating it can be time-consuming because the calculation depends on many factors.
However, comparing the technical debt of two versions of a codebase can provide a good indication of how its code quality is evolving.
Comparing the debt metrics of two versions helps minimize estimation errors and provides a more meaningful measure of change.
Conclusion
Technical debt is a powerful metric for monitoring codebase quality. However, users need an easy way to calibrate the calculation and reduce estimation errors. In practice, tracking how technical debt evolves over time is often more useful than focusing on the absolute value itself.