The term “technical debt” is widely used in the industry even if there isn’t a clear definition of it and almost nobody uses the term in the way Ward Cunningham meant when he first coined it. It’s most commonly used to describe things in our environment, usually but not always code, that slow us down. These are things that are working - not bugs - but that are implemented in a poor way that makes them more difficult to understand or modify.
These things could range from poor variable naming or duplication in the code all the way up to architectural concerns like having three different ways to solve the same problem in the same code base.
This technical debt is all waste at some level and slows down our ability to get work done. A 2018 study on technical debt, attempted to draw some conclusions on exactly how much waste.
The analysis of the reported wasted time revealed that developers waste, on average, 23% of their development time due to technical debt and that they are frequently forced to introduce new technical debt due to already existing technical debt.1
This is more than a day a week in lost productivity due to the presence of technical debt. Keep in mind that this is also an average and we know that some companies are very good at keeping their code clean so this means that many companies are far worse than this.
As we’re focusing on tracking our flow metrics, this is a place that will have a significant impact. This will have a direct impact on aging and cycle time of individual items as we struggle to complete them.
How much time should you spend “paying back” technical debt? There’s no hard data on this, although the general consensus seems to be that we need to spend 20% of our time in cleaning up debt, just to avoid falling further behind.
What happens if we just ignore the debt and allow it to continue growing? We’ll get slower and slower over time until we eventually give up on this code base and do a rewrite. We sometimes call this technical bankruptcy. We’ve seen code bases hit this point in as little as two years - where they have to be thrown away and rewritten from scratch.
Conversely, we’ve seen ten year old code bases that were clean and easy to work with. The difference between the two is the amount of effort we spend paying back that technical debt.
-
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 ↩