What is technical debt?
Technical debt is the extra work every future change to a piece of software requires because a quick solution was chosen over a sound one at some point in the past. It builds up through shortcuts in code, architecture, testing and operations, and it keeps growing until someone pays it down.
Ward Cunningham introduced the term in 1992 as a comparison with a loan. A quick solution is borrowed money: you ship sooner. In return you pay interest, in the form of additional effort every time someone touches that part of the system. Paying off the principal means reworking the code so the extra effort goes away.
The comparison shows that debt is not bad in itself. Borrowing can be the right call when a deadline matters most. Technical debt becomes a problem when nobody knows it exists, nobody pays it back, and the interest takes up a growing share of your development time.
Types of technical debt
Deliberate or accidental
Deliberate debt is taken on with open eyes. The feature has to ship for the trade show, and the clean version comes later. That is reasonable if the decision is written down and a date for repayment exists. Accidental debt builds up without a decision. The team did not know the better approach, the requirements changed, or a library aged over the years. It is harder to manage because it is on nobody's list.
Where it accumulates
- Code
Copied logic, very long functions, unclear names. Every change has to be repeated in several places.
- Architecture
Modules that are tightly tangled. A change in ordering unexpectedly breaks something in billing.
- Tests
Missing or unreliable automated tests. You only find out in production whether a change broke something.
- Dependencies
Frameworks, libraries and runtimes that are several major versions behind or no longer maintained by their vendor.
- Documentation
Decisions and system context are not recorded anywhere. New hires take a long time to become productive.
- Infrastructure
Servers configured by hand, manual deployments, no monitoring. Operations depend on steps only a few people know.
How to spot technical debt in day-to-day work
You do not need to read code to notice technical debt.
- Changes take longer than they used to. Requests of similar size need noticeably more time than two years ago, although the team has not shrunk.
- Releases make people nervous. Deployments get postponed, bundled and scheduled for off-hours because everyone expects problems afterward.
- Knowledge sits with individuals. Certain parts of the system are touched by one person only. When that person is on vacation, the work waits.
- Versions are out of date. The framework, database or operating system no longer receives security updates from its vendor.
If several appear together, you are most likely dealing with a legacy system whose debt has grown over years.
Measuring technical debt
Technical debt cannot be expressed as a single number. You can track a handful of metrics that together give a reliable picture. Watch how they develop over time in your own system. A generic benchmark tells you much less.
- Lead time for changes
Time from starting work to delivery to users. If it rises for tasks of similar size, the interest is growing.
- Change failure rate
Share of releases that lead to a production incident, a rollback or a hotfix.
- Test coverage
Share of the code exercised by automated tests. Coverage of the business-critical parts matters more than the overall figure.
- Outdated dependencies
Number of libraries with known vulnerabilities or without vendor support. Common package managers produce this list automatically.
- Static analysis
Tools check the code for complexity, duplication and rule violations. The results show where problems cluster.
It helps to combine two views: which files are hard to understand, and which files change often? Debt in a module nobody has touched in years costs almost no interest. Debt in a module that changes every week costs interest constantly. Start there.
What doing nothing costs
The cost of technical debt does not appear on any invoice. It shows up elsewhere:
- Speed: New features reach the market later because part of the team's time goes into workarounds.
- Security: Unsupported components get no fix when a vulnerability becomes known.
- Outages: Defects after releases disrupt operations and tie up developers with emergency fixes.
- People: Developers do not like working in a hard-to-maintain system for long. When the person holding the knowledge leaves, the risk jumps.
- Room to act: The longer you wait, the fewer options remain. A rebuild you could have planned turns into a replacement under time pressure.
Five ways to reduce technical debt
Start with the smallest strategy that solves your problem.
1. Clean up as you go
Whoever changes a piece of code tidies it a little along the way. This costs little and improves the parts that are actively worked on. It is not enough for large structural problems.
2. A fixed share of every sprint
The team reserves a fixed part of every sprint for paying down debt. How large that share should be depends on your system. What matters is that it is not dropped whenever a deadline gets tight.
3. Targeted refactoring
A clearly bounded area is reworked as a project of its own, for example the module that produces the most defects. This requires tests that pin down the current behavior. If they are missing, they are written first.
4. The strangler approach
The old system is replaced step by step. New features are built in a new application, and existing features move over piece by piece until the old system can be switched off. Operations continue throughout. This is also how we usually approach software modernization.
5. A full rewrite as the last resort
A complete rewrite is the most expensive and riskiest option. It is justified when the technical foundation can no longer carry the system, for example because the platform is no longer supported. You can test whether the new approach holds up with a proof of concept on a small, critical slice.
Explaining technical debt to management
"We need to refactor" does not convince anyone who has to approve a budget. Translate technical debt into consequences for the business.
- Describe the effect, not the cause. Instead of "the code is messy," say "a pricing change in the portal takes several weeks and ties up two developers."
- Show the trend. Your own metrics over several quarters show whether things are getting better or worse.
- Name the risk. What happens when the database version stops receiving security updates, or the only person who knows the system resigns?
- Present options. Two or three paths with effort, duration and effect. Include the option of doing nothing, along with its consequences.
Technical debt is a question of priorities, not of blame. Once it is visible, you can make a decision about it.
When an external audit makes sense
Your own team knows the system best. Still, an outside view helps in some situations:
- Before a larger investment, when you have to choose between modernizing and rewriting.
- When management and development disagree about the state of the software.
- When the system was built by a vendor or a previous team and documentation is missing.
- During an acquisition, succession or funding round, when a technical assessment is required.
An audit does not replace the cleanup. It gives you the basis for it: a prioritized list of risks, a target picture and a plan with a budget range.
Frequently asked questions
Is technical debt always bad?
No. A deliberate shortcut can be right when a deadline demands it, as long as it is recorded and paid back.
Can technical debt be eliminated completely?
No. Software under active development keeps taking on new debt. The goal is a level at which changes stay predictable.
What is the difference between technical debt and legacy software?
Legacy software is an old system that is still in use. Technical debt is the extra effort built into a system. Legacy software almost always carries a lot of debt, but a young system can have it too.
Who is responsible for reducing it?
Developers identify and fix the debt. The decision about time and budget lies with management or the product owner. Without that decision, the work does not get done.
How long does it take to reduce technical debt?
That depends on the size and condition of the system. Improvements in frequently changed areas are often noticeable after a few sprints. Replacing a legacy system step by step takes many months.
Next step
Onveda has been building software for mid-sized companies since 2010, based in Langenfeld, Germany. If you want to know where your system stands, our Software Audit reviews architecture, security and maintainability in two weeks at a fixed price of €3,000 to €6,000. You get a prioritized list of risks, a 90-day plan and a budget range. If you would rather talk through your situation first, get in touch.
