Technical Debt
Technical debt is what happens when a team takes shortcuts to deliver something quickly, knowing they will need to go back and fix it properly later.
It is like cramming everything into a wardrobe to tidy your room fast — the room looks fine now, but eventually you will have to organise that wardrobe properly. In software, technical debt slows teams down and makes future changes harder and riskier.
Technical Debt, explained at three levels
At home
Technical debt is like taking a shortcut that saves time now but causes problems later. Imagine building a bookshelf without measuring properly — it works for now, but when you try to add more shelves later, nothing fits right. In software, it means the code works today but is messy underneath, making it harder and slower to add new features or fix bugs in the future.
At work
In business, technical debt accumulates when teams prioritise speed over quality — which is sometimes the right decision under time pressure. However, like financial debt, it accrues interest. The longer it goes unaddressed, the more it slows down development, increases the risk of bugs, and makes the system harder to maintain. Managing technical debt is about making conscious trade-offs, not avoiding all shortcuts.
At home
Technical debt takes many forms. It can be messy code that is hard to understand, outdated libraries that need upgrading, missing automated tests, poor documentation, or architectural decisions that no longer fit the system's needs. Some debt is deliberate (we chose speed over perfection) and some is accidental (we did not know a better way at the time).
At work
Organisations manage technical debt by making it visible — tracking it in the backlog alongside feature work — and allocating regular capacity for paying it down. Common approaches include dedicating a percentage of each sprint to debt reduction, scheduling periodic hardening sprints focused on quality, and establishing quality standards (Definition of Done) that prevent the most harmful debt from accumulating.
At home
Quantifying technical debt involves metrics like code complexity scores, test coverage gaps, dependency vulnerability counts, and the ratio of time spent on maintenance versus new features. Tools like SonarQube can scan codebases and identify hotspots. The key decision is prioritisation — which debt causes the most drag and risk, and should therefore be addressed first.
At work
Advanced technical debt management involves architectural fitness functions that automatically detect drift from design principles, dependency analysis tools that map coupling and identify fragile components, and economic models that calculate the cost of delay for debt remediation. Strategic debt requires deliberate architectural evolution plans, while reckless debt demands immediate attention through refactoring, re-platforming, or in extreme cases, rewriting components.
Real-world examples
At home
Kai built a personal website quickly for a job application deadline. He copied and pasted code rather than writing it cleanly. It worked perfectly for the interview, but six months later when he tried to add a portfolio section, the messy code made the change take five times longer than it should have. That was his technical debt coming due.
At work
Sophie's development team rushed to launch a new feature before a trade show, skipping automated tests and using a quick workaround for the payment flow. Three months later, when they tried to add international payments, the workaround made it enormously complicated. They spent two weeks refactoring the payment code before they could add the new feature — time that would have been unnecessary if they had built it properly the first time.
Common confusions
- Some people are convinced that all technical debt is bad. Deliberate, well-managed debt taken for strategic reasons (like meeting a critical deadline) can be a valid business decision.
- It's a popular misconception that technical debt is only about messy code. It includes outdated dependencies, missing tests, poor documentation, and architectural limitations.
- There's a widespread belief that technical debt can be fixed in one big effort. It is best managed through regular, incremental improvement as part of normal development work.
For analysts
Make technical debt visible to business stakeholders by translating it into terms they understand. Instead of saying 'we need to refactor the payment module,' say 'adding new payment methods currently takes four weeks instead of one because of how this was originally built; investing one sprint in cleanup will save us months over the next year.' When business people understand the cost of debt in terms of delivery speed and risk, they are much more likely to support addressing it.
History & origin
Ward Cunningham coined the term 'technical debt' in 1992 to explain to business stakeholders why software sometimes needs rework. He used the financial metaphor of debt — you can borrow speed now by taking shortcuts, but you pay interest later in the form of slower development and more bugs. The concept has since become a fundamental part of how software teams discuss code quality and sustainability.