Technical debt in companies: how to resolve legacy without stopping the business

How to identify and quantify technical debt

• Critical technical debt signals: new developer onboarding longer than 3 weeks, more than 30% of sprints spent on bugs instead of features, manual testing because code isn't testable, and patches on patches nobody understands.
• Quantification in euros: calculate the opportunity cost. If a 2-week development takes 6 weeks due to technical debt, the cost is 4 weeks × team cost. With a 3-person team at €6,000/month each, that's ~€18,000/month in inefficiency.
• Analysis tools: SonarQube for quantified code debt, Datadog or similar for tracking production incidents from legacy code, and structured team interviews to find system 'untouchables'.
• Prioritise by impact: not all technical debt is equal. Debt blocking new features is P1; debt that slows but doesn't block is P2; cosmetic or architectural debt with no performance impact is P3.

Refactoring vs. rewriting: how to decide

• Refactoring: when existing code is functional but messy, has tests (or tests can be written), and the overall architecture is sound. Safer, slower, no risk of optimistic second-estimate syndrome.
• Rewriting: when the architecture is fundamentally wrong, code isn't testable by design, or the tech stack has become obsolete. Higher risk — the second version always takes twice as long as estimated.
• Joel Spolsky's rule: never throw it all out and start from scratch unless absolutely unavoidable. The existing software, however ugly, contains decades of implicit business knowledge that isn't documented.
• The most effective hybrid approach: strangler fig pattern — surround the legacy system with new modules that progressively replace functionality while the old system keeps running in production.

Strategies for resolving debt without stopping the business

• Reserve 20-30% of team capacity for technical debt in each sprint. Not a dedicated sprint every 3 months — a constant percentage. 'Refactoring-only sprints' rarely happen.
• Define the Boy Scout Rule: the team commits to always leaving the code slightly better than they found it. Small continuous improvements add up more than big remediation projects.
• Set a Definition of Done with technical criteria: no ticket closes without test coverage, basic documentation, and code review. Prevents debt from being generated in the current sprint.
• Communicate to management in business terms: not 'we'll refactor the orders module' but 'we'll reduce the time to add new integrations from 6 weeks to 2 weeks, enabling us to launch the [Platform X] integration before Q2'.

How to prevent future technical debt accumulation

• Modular architecture from the start: well-decoupled systems age much better. Each module should be able to evolve independently without affecting the rest.
• Tests from the start: code without tests is technical debt from day one. The time 'saved' by not writing tests is paid with interest in every subsequent bugfix.
• Mandatory code review: technical problems caught in review cost 10% of what they will cost once they are in production.
• Quarterly technical review: schedule a session every 3 months to assess system technical health, update dependencies, and plan next quarter's debt before it becomes urgent.

Related resources