Tech Debt
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 means every new feature takes twice as long, until development eventually grinds to a complete halt.
- 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).
- 20% Rule: A fixed allocation of approximately 20% of development time for Refactoring, updates, and debt repayment.
- 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. You don't see it from the outside at first, but eventually the machine breaks down or becomes extremely slow. We invest in the operational reliability of your organisation.
How do we prioritise Refactoring against new features?
Measure the Velocity of your 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.
Reference Guide
- Technical Debt (Martin Fowler): The classic definition and the quadrant model. martinfowler.com
- Refactoring: Martin Fowler on techniques for debt repayment. refactoring.com
- The Leprechauns of Software Engineering: Laurent Bossavit on myths and facts in software development. Leanpub