Technical debt is made up of all those things in our system (architecture, code, documentation, etc) that are working but are of sufficiently poor quality that they cause us to move slower when implementing new functionality. Perhaps we need to do additional testing before we can add something new or we need to refactor the code to make it cleaner or more extensible. Perhaps it’s just hard to read or understand and therefore difficult to know how to add the new functionality.
Note that while I normally distinguish between technical and architectural debt, I’m lumping them together in this article.
Perhaps we learned a newer, better, way to solve the problem and started to use that, but never went back to all the old code to change it to the new way. Now we have two ways of solving the same problem.
This isn’t what Ward Cunningham had in mind when he first coined the term but it’s how the term is used today.
On average, developers waste 23% of their development time on technical debt. Over a day a week.1
A 2018 study on technical debt showed “that software developers report that they waste on average 23% of their working time due to technical debt.”1 That’s over a day a week per developer in lost productivity. Furthermore, the same study showed “that in almost a quarter of all occasions when encountering technical debt, the developers are forced to introduce additional technical debt due to the already existing technical debt.”1
So not only are we losing a day a week on average, but the technical debt continues to grow and we get even slower. At some point, we’ll declare technical bankruptcy and rewrite the system from scratch. Of course, we never admit that’s why we’re rewriting the system. There’s always some justification about how the old platform just wasn’t good enough for what we need and we needed to move it.
Re-platforming a system is almost always the wrong answer but that’s a topic for a different day. If we allow the technical debt to grow uncontrollably then we’ll have no choice and will be forced to rebuild the system. I’ve seen far too many of these over my career and almost all of them could have been avoided with good attention to paying back technical debt.
“This study provides new insights into technical debt research by revealing that the developers are largely aware of the amount of the time they waste due to technical debt. However, the study shows that the developers’ managers are not as aware of the amount of time developers waste, and that the different professions seem to have different views on what is a reasonable and unreasonable amount of time to waste due to technical debt.”1
Notably, there was a difference in what developers and their managers thought about the results. Overall, the developers had a much higher awareness of the waste due to technical debt and seemed to accept it as inevitable. Their managers on the other hand were not aware and were really not happy to hear how much there was. The disconnect between the two is quite interesting.
In 2020, McKinsey surveyed 50 CIO’s with revenues over one billion, and found that 10-20% of technology budget allocated to new projects is spent on dealing with technical debt. This is an astoundingly high number and given that managers are less aware of how much time we really spend than developers, it may be low.
While I’m not aware of any studies that can confirm or deny this, discussions at various agile events finds agreement that if we aren’t spending 20% of our time paying back technical debt, we’re falling further behind. The further we fall behind, the slower we go.
What’s your strategy for dealing with technical debt? Shockingly, many companies don’t have one.
See also: How technical debt increases cognitive load and inhibits learning.
-
Terese Besker, Antonio Martini, and Jan Bosch. 2018. “Technical debt cripples software developer productivity: a longitudinal study on developers’ daily software development work.”” In Proceedings of the 2018 International Conference on Technical Debt (TechDebt ‘18). Association for Computing Machinery, New York, NY, USA, 105–114. DOI:https://doi.org/10.1145/3194164.3194178 ↩ ↩2 ↩3 ↩4