Technical debt is a prominent topic for any company running code as its main asset. However, unlike many other part of the company, there is often no clear metric about it.
And there is a good reason for that: it's complicated.
At Vialma, I need to measure it in order to be able to evaluate our debt, to track it, and to pay it back!
Main features of the metric
The metric I came up with is compound. It is hard to list and understand everything involved in technical debt. However, some features are more obvious than others. I focused on them.
Technologies versions. I met a company that were working on Django 1.*. That's debt. I consider here web server versions (apache, nginx, ...), language version (Python, PHP, ...) or framework version (React, Symfony, ...). In this metric, I compare the current version of our technology with the latest version on the market, and count the number of days elapsed since the release of that version.
Tests. The code can be ugly... but if it's tested, at least we know it is doing what we expect out of it. A code without tests is very likely to become an important debt to the company.
Dependencies. The technical debt of a highly dependent code will grow very fast. It is easier and faster to code with many dependencies at first, however much harder to maintain it. I include dependencies in my metric.
About the metric value
The metric above is 5.48. It does not mean much by itself, what is of first interest to me is how it is progressing from one month to the other.
It will naturally grow, since the elapsed days of latest technologies continuously grow. Decisions to merge projects, bootstrap new technologies, waiting too long for refactoring or avoiding tests will now have an impact on the metric. It's exactly what I wanted!
Why managing technical debt is important?
It is not always obvious to business or product owners. I like to remind the importance of technical debt control on the business this way:
Development time: a clean, maintained code makes any new development faster, whatever the experience of the developer. This can be counter-intuitive to some developers when you think of the time you need to code and maintain tests, but it truly is!
Stack attractiveness: it is hard to hire PHP developers already... It is MUCH harder if you are running Symfony 3 on PHP 5...
Maintenance time: you can't safely move from version X to X+1 if your code is untested and unstable. What happens too often is that migration is never planned ("we didn't have time"!)
Conclusion
Technical Debt is not a bogeyman in the company any more. It is a controlled variable behind a transparent, simple metric, like any other important business matter.
I would like to add more features to this metric later, like the number of developers per project, code coverage (instead of lines of test code), security issues detected by Snyk or a similar tool, or the number of errors raised in production with Sentry or Kibana for example.
Maybe for a version 2 of the metric!
Top comments (1)
Hello,
Are you willing to share exactly how you measure the technical debt? From what I can tell, you only shared a screen shot of an Excel spreadsheet. I would appreciate if you did, but if not, that is also fine.
Cheers.