Technical Debt
Last updated:
Debt is compromise you chose on purpose — it becomes dangerous when teams stop naming it.
01 — Purpose
Debt is compromise — name it
Technical debt is accumulated compromise. It is dangerous when teams pretend it does not exist.
Not all debt is bad. Shipping deliberately — with a plan to revisit — is how products move. Unnamed debt, duplicated systems, and “we will fix it later” with no ticket is how codebases become unmaintainable.
02 — Healthy
Healthy debt
Healthy debt is visible, bounded, and scheduled.
- documented — ticket, ADR, or README note with context and owner
- prioritised — in backlog with estimate, not infinite “tech debt sprint”
- temporary — expiry date or trigger to remove (“after migration ships”)
- trade-off explained — what you gained by deferring proper work
03 — Dangerous
Dangerous debt
These patterns compound until every feature takes twice as long.
- hidden complexity — behaviour only one person understands
- abandoned architecture — old and new systems running in parallel forever
- duplicated logic — copy-paste across apps with no shared owner
- accessibility or performance debt ignored because “users have not complained”
- dependencies left unmaintained with known vulnerabilities
04 — Practice
Managing debt as a team
Debt becomes dangerous when acknowledging it is treated as failure.
- reserve capacity each cycle for debt reduction — not only features
- review debt in retros — what slowed us down this sprint?
- do not add debt to hit arbitrary dates without stakeholder consent
- prefer small repayments over multi-year “rewrite” projects without users
The goal is not zero debt. The goal is debt you understand, can explain, and are actively paying down.