How do I handle technical debt?
Make it visible, rank it by how much it slows you down or puts you at risk, and pay it down steadily alongside feature work instead of waiting for a big rewrite. Some technical debt is a fair trade for speed; the problem is debt nobody tracks.
Last updated
A practical approach
- 1List it: a short register of known debt with where it is and what it costs you.
- 2Rank it by impact: what slows every change, what causes incidents, what is a security risk.
- 3Reserve a steady share of each sprint for paying it down.
- 4Fix debt in the code you are already changing for a feature.
- 5Add tests before refactoring risky areas.
- 6Keep dependencies current with small, regular upgrades.
When a rewrite is worth it
Rarely all at once. Rewrites take longer than planned and pause feature work. A gradual replacement, one module or service at a time behind stable interfaces, usually gets the benefit with far less risk.
Check it for your case.
Common follow-up questions.
How do I explain technical debt to non-engineers?
As interest: each shortcut makes future changes slower and riskier until it is paid back. Show the features or incidents it is slowing down.
Is AI-written code more prone to debt?
It can be if it is accepted without review. Treat AI output like any other code: review it, test it and keep it consistent with the codebase.
Can a new team take on a codebase with lots of debt?
Yes, with a proper handover and an honest assessment first. Expect slower progress at the start.
Related questions and guides.
- What does software maintenance cost?Question
- How do I hand over a software project?Question
- How do I migrate off no-code?Question
- AI agent vs workflow automationComparison
- RAG vs fine-tuningComparison
- GlossaryEvery term, in plain words.
- Embedded engineersOceanLab engineers working inside your team.
- BacklogGlossary
- VelocityGlossary
