Technical Debt is a form of Entropy, a form of system degradation. Whenever monkey patches are written to address problems, hasty code is shipped, necessary refactoring is omitted, temporary decisions are made permanent then Technical Debt is created.
If this Technical Debt is not payed, that is time is invested to straighten out the fragile state, to provide a durable solution, to actually think it through - then Technical Debt keeps growing.
This ever growing Technical Debt requires increasingly more maintenance cycles to be kept in check - that is: to keep things running at status quo.
Any engineering organization has a specific amount of capacity. Technical Debt continuously consumes capacity every cycle. The amount of capacity consumed by Technical Debt can match or even outgrow the available capacity - if not addressed.
Solution to mitigate or eliminate Technical Debt - besides limiting wonky decisions - is to dedicate capacity within every cycle to address existing and new Technical Debt. Experience taught us that any organization, that does not invest at least 20% of their capacity each cycle into that (i.e. making it part of normal operations), will loose the battle and will sooner or later be left with no capacity at all.
Sources
- Wikipedia: Technical Debt
- Atlassian: Escaping the black hole of technical debt
- DevOps Handbook, Chapter 11 & 21
Related
