In my previous article, I wrote about why I think managing technical debt is challenging; in this essay, I will answer another critical question that remains open.
Why technical debt is hard to measure?
Adam Tornhill, in the introduction of his book Software Desing X-Ray, wrote:
“Repaying technical debt is hard due to the scale of modern software projects; with hundreds of developers and many technologies, no one has a holistic overview. We’re about to change that.”
After you finish reading the whole book, hopefully, you will have a better understanding of this concept, you will have more techniques to analyze your code base technical debt, and at the end, you will discover how hard it is to deal with the interest rate costs that arise with any technical product (or any product at all) I promise you will conclude it is not easy to change that fact.
The truth is that technical debt is burdensome to measure efficiently; first, because not all technical debt can be discovered in the source code files, and second, because you are dealing with many quantitative and qualitative measuring factors that come from complex assumptions and challenging to know if are valid or what and how you measure it is the correct way to do it.
It’s hard to be confident that what you are measuring has a valid weighted importance on the interest rate factor that the different levels of technical debt are creating over time.
You can see in this conference how even one of the most used code bases (Android Platform Framework) written by one of the twenty-century top tech companies incurs harmful practices that are hard to change later.
Even using advanced data science techniques, static code analysis, and behavior code analysis and defining new terms like technical debt dimensions, code change frequency, code health, code, and cyclomatic complexity is not enough, and instead of making the developer process easy is just adding more complexity that maybe only expert dedicated teams and optimistic cash flow startups can afford to pay.
I believe there is no easy cure for this illness because it is hard to borrow features and techniques from the future that still do not exist and minimize the consequences of the past in a world of technical options and human biases.
Still, hopefully, one cure to all this is creating a small, 10X, and laser-focused technical team with lower debt tolerance, managed by obsessive technical expert managers inside top innovative small organizations that know about the existence of Lehman laws of software evolution, understand and successful document everything they can and accept that good software is written in cycles and maintained over time in a hopefully evolutionary process, that needs to be planned with no so tight schedules.
But we all know that in the real world, not all clouds are blue.