Tech Debt
Visible debt can be managed; invisible debt sets the pace
Technical Debt consists of conscious or unconscious architectural decisions that save time in the short term but increase maintenance costs and slow down development velocity over time. Like financial debt, technical debt must also be "serviced" and eventually "paid off".
The goal is not complete debt freedom (which would be unrealistic), but controlled management that preserves the IT organisation's capacity to innovate.
Anti-Patterns: The Debt Trap
- Unconscious debt accumulation: Teams are unaware they are building up debt because no architecture reviews take place.
- Compound interest effect: Debt in core components can measurably increase lead time and raise defect risk, especially in areas that change frequently.
- Refactoring ban: Management allows no time for clean-up work because only "visible features" count.
Managing the Debt
- Visibility (Tech Debt Registry): Capturing technical debt in a backlog or directly in the code (e.g. via TODO tags).
- Categorisation: Distinguishing between "deliberate debt" (Speed to Market) and "inadvertent debt" (lack of quality).
- Debt Repayment Budget: An explicit allocation of a portion of development time for refactoring and updates. Around 20% is often discussed as a starting heuristic; the right share depends on the current debt level, change frequency, and priorities.
- Dependency Bankruptcy: The courage to completely rebuild components when repaying the debt would cost more than developing it from scratch.
- Quality Gates: Automated checks in the CI/CD pipeline that prevent new, obvious debt from being introduced.
The Focus: Investing in Speed
Repaying technical debt is not a leisure activity for developers, but a necessary investment to secure the time-to-market for future features.
FAQ
Why should we pay for things the client doesn't see?
Because technical debt is like rust on a machine. It is not visible from the outside at first, but eventually the machine breaks down or becomes extremely slow. The investment is in the operational reliability of the organisation.
How do we prioritise Refactoring against new features?
Measure the Velocity of the teams. If it drops over months with the same team size, that is a clear signal that the interest burden of technical debt has become too high.
References
- Martin Fowler Refactoring: Improving the Design of Existing Code. Techniques for systematic debt repayment. (2018). refactoring.com
- Laurent Bossavit The Leprechauns of Software Engineering. On myths and unsupported numbers in software development. (2012). leanpub.com/leprechauns
- Martin Fowler Technical Debt Quadrant. The classic definition and the quadrant model of technical debt. (2009). martinfowler.com/bliki/TechnicalDebtQuadrant.html