Every developer wants clean code that is easy to read and maintain, with few issues and bugs. And there’s no magic solution to achieve this goal: each company has its own best practices and coding rules, and tries to define a process to keep the code very clean.
Measuring the code quality of a project is not an easy task; many tools provide their own algorithms to evaluate it, based on many factors:
- Issues detected by the static analysis tools.
- Code coverage.
- Code duplication.
- Documentation.
- Lack of design.
There’s a metric that gives us an estimated value for an approximate overall view of our code base quality: the technical debt metric.
From Wikipedia we can get a brief explanation of technical debt:
Technical debt (also known as design debt 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”.Technical debt can be compared to monetary debt. 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.
In theory, it’s very promising to deal with technical debt to improve software quality, but in practice it’s not easy to use; indeed, the big challenge is how to evaluate technical debt.
Whatever the tool or method used to evaluate it, it must be flexible and easy to customize. The company must be able to calibrate its algorithm depending on its context: indeed, one team could tolerate a method with more than 50 lines of code, while another could choose 30 as the maximum.
An agile algorithm to the rescue
There are two options to make debt calculation flexible:
- Define a specific algorithm and make it possible 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 flexible; it can be changed for each rule, depending on the project context.
For example, here’s a formula for the debt introduced by overly large types:
And here’s another formula for a Cppcheck issue:
This way, each team can configure their debt calculation depending on the project context, which helps reduce estimation errors in the debt calculation.
The comparison with a baseline
It’s very difficult to evaluate technical debt; every algorithm used introduces many estimation errors, and we don’t have much time to calibrate it — it depends on many factors.
However, if we compare the technical debt of two iterations of a code base, we can get a good idea of 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.
Trends to track the evolution
Concepts like technical debt help quite a bit. But nothing hits home like a visual.
For instance, you might want to look at average cyclomatic complexity and lines of code per method. Generally speaking, you would expect these figures to remain relatively flat (and low) in a codebase. You could use a trend chart to confirm this and keep tabs.
Does the trend line stay pretty much flat, with a little uptick or downtick here and there? Or does it trend slowly but steadily upward? Observing a trend like this can help you catch an issue much earlier than you otherwise might. Whenever I see a codebase with heinous method complexity, I understand that nobody went in and made it that way in an afternoon. It took years of not noticing a general, gradual trend.
Conclusion
The technical debt metric is a powerful way to control code base quality. However, the user must have an easy way to calibrate it and reduce estimation errors. And it’s more useful to rely on the evolution of technical debt than on the debt itself.