Technical Debt
Technical debt is the extra future cost created when software is built with shortcuts, such as copied code, missing tests or outdated components, to save time today. Like financial debt it accrues interest: each change takes longer and breaks more often until the shortcuts are fixed.
Key Facts
| Symptoms | Simple changes take weeks, frequent bugs after releases, only one developer understands the system |
|---|---|
| Common causes | Rushed deadlines, no code reviews, outdated frameworks, missing documentation |
| Paying it down | Refactoring, adding tests, upgrading dependencies, documenting |
| Budget rule of thumb | Many teams reserve 15–25% of development time for it |
Why it matters to the business
Technical debt shows up as slower delivery, outages and dependence on individuals. It is invisible on the balance sheet but real in lost time and missed opportunities.
When to pay it down
- Before building major new features on a fragile part.
- When a key developer is leaving.
- When security updates can no longer be applied.
See legacy system modernisation: rewrite, refactor or wrap.
Frequently Asked Questions
Is all technical debt bad?
No. Deliberate, recorded shortcuts to test an idea quickly can be sensible, as long as they are repaid.
How do I measure technical debt?
Track delivery speed, bug rates after releases and the age of key dependencies; an independent code review gives a clearer picture.
Related Glossary
Need help implementing this in your business?
Turbo Bytes Consulting helps businesses streamline operations and build custom software architectures that scale without chaos.