Quick answer
Technical debt is the future cost created when software is built quickly or imperfectly. Shortcuts, outdated libraries and missing tests make later changes slower and riskier. Managing technical debt means tracking it, ranking it by impact and fixing it steadily.
Key takeaways
- Some debt is deliberate and sensible.
- Unmanaged debt slows delivery and increases risk.
- Rank items by business impact, not by developer annoyance.
- Fix a little in every release.
What are the warning signs?
- Simple changes take far longer than they should.
- Bugs return after being fixed.
- Only one person understands a key part of the system.
- Updates are avoided because they might break something.
- New staff take a long time to become productive.
Where does it come from?
| Source | Example |
|---|---|
| Deadlines | Skipping tests to launch on time |
| Ageing tools | Unsupported framework versions |
| Poor design | Tightly tangled code |
| Missing documentation | Knowledge only in someone's head |
How do you make it visible?
- List known problems in a shared backlog.
- Tag each with the area affected.
- Rate impact and effort.
- Review the list with the business, not just developers.
How do you pay it down safely?
Do not stop everything for a rewrite. Reserve a share of each sprint for debt, and fix the areas you are already changing.
Add automated tests before big changes, so you can tell when something breaks.
When to bring in help
If delivery has slowed sharply, or security updates are overdue, an independent code review can show what needs attention first.
A fair way to prioritise
| Priority | Type of debt |
|---|---|
| High | Security updates and unsupported software |
| Medium | Areas that change often and break often |
| Low | Ugly code that rarely changes |
This keeps effort on what could actually hurt the business. Review the list each quarter, because low-priority items can quietly become urgent as the product grows. Share the ranked list with stakeholders so everyone understands why some fixes wait and others do not.
Bottom line
Technical debt is a normal cost of building software, but ignored debt gets expensive. Make it visible, rank it by risk and fix a little in every release.
Sources and further reading
Checked against the sources above and our own project experience. Last reviewed 7 October 2026.
