The Problem with Technical Debt
Technical debt is like financial debt: a little is normal and even sensible. Too much of it brings the entire system to a standstill.
The metaphor is apt because it captures the compound interest effect. A quick fix saves time today but costs more tomorrow. And even more the day after. Eventually, the team spends more time working around the debt than on actual feature development.
The problem is not that technical debt exists. The problem is that most teams have no plan for paying it down.
Why "20% for Tech Debt" Doesn't Work
The most popular approach – "we'll reserve 20% of our capacity for technical debt" – almost always fails in practice. The reasons:
No prioritisation: 20% of the time is spread across arbitrarily chosen improvements rather than the debt with the greatest impact. The result: lots of activity, little effect.
No commitment: As soon as a feature becomes urgent (and features always become urgent), the 20% gets cut. After three sprints, the plan is forgotten.
No measurability: Nobody can say whether the time invested actually improved anything. Without measurement, there is no accountability.
A Better Approach: The Debt Inventory
Step one is a complete inventory. Not in people's heads, not on sticky notes, but as a documented, prioritised list.
For each entry, we capture four dimensions:
Impact on development velocity: How much does this debt slow the team down? Measured in estimated time per sprint lost to workarounds.
Risk: What happens if we do nothing? Security vulnerabilities? Data loss? Performance degradation? Or "just" frustration?
Effort to fix: How many person-days do we need for the fix? A T-shirt size estimate (S/M/L/XL) helps here.
Dependencies: Does this debt block other work? Or is it isolated?
The Prioritisation Formula
From these four dimensions, we calculate a simple score:
Priority = (Impact x Risk) / Effort
Debt with high impact and risk at low effort comes first. These are the "quick wins" that deliver immediately noticeable improvement and build momentum.
At the other end sit items with low impact and high effort. These are consciously accepted – not ignored, but documented and set to "later".
Integration into Day-to-Day Operations
The key to successful debt reduction is integrating it into the normal development process – not as a separate project, but as part of every task.
The Boy Scout Rule: Every pull request leaves the code better than it found it. Not as a major refactoring, but as a small, incremental improvement. A better variable name here, an extracted interface there.
Feature-linked debt reduction: When a feature branch touches an area of the code that has technical debt, the debt reduction becomes part of the feature. Not optional, but as part of the Definition of Done.
Dedicated debt sprints: Instead of 20% every week, one full sprint per quarter. Focused, planned, with clear objectives and measurable results. This is more effective than permanent background work.
Refactoring Strategies That Work
Large-scale refactorings frequently fail because they take too long and affect too many parts of the system at once. Targeted strategies are better:
Strangler Fig Pattern: New functionality is built in a clean architecture. Old functionality is migrated step by step, piece by piece, until the old system is empty and can be switched off. No big bang, no risk.
Branch by Abstraction: An abstraction layer is introduced between the old and the new code. Both implementations exist in parallel. The switch happens via a feature flag. Once the new implementation is stable, the old one is removed.
Parallel Run: Critical system components are rebuilt and operated alongside the existing system. The results are compared. Only when the new implementation is demonstrably correct is the switch made.
Preventing Debt Rather Than Reducing It
In the long run, prevention is more effective than reduction. Some measures that have proven to help:
Architecture reviews before implementation: 30 minutes of design discussion saves days of refactoring. Not every feature needs a review, but anything that alters the existing architecture should be discussed beforehand.
Automated quality gates: Linting, type checking, test coverage thresholds, dependency audits – everything that can be checked automatically should be checked automatically. In the CI pipeline, not optional.
Documented architecture decisions: Architecture Decision Records (ADRs) capture why a decision was made. This prevents later developers from unwittingly working against the architecture.
How to Explain the Value to Stakeholders
The most common reason technical debt is not addressed is not technical. It is political. Stakeholders do not see the value.
The language that works is the language of business outcomes:
Not "We need to refactor the database", but "The current database structure limits our release velocity to two features per month instead of four."
Not "The code is unreadable", but "New developers currently take three months to become productive. After the refactoring, it will be four weeks."
Not "We have technical debt", but "Maintenance costs are rising by 15% per quarter. Without countermeasures, they will exceed feature development costs within six months."
Conclusion
Technical debt is unavoidable. But it is manageable – if you treat it as what it is: a business decision that requires regular attention.
The key is not perfection, but system. A documented inventory, a clear prioritisation, integrated reduction in daily operations, and preventive measures. That sounds like a lot of effort, but it is considerably less than the alternative: a system that grinds to a halt under the weight of its debt.