Technical debt is the accumulated cost of shortcuts in software: a quick fix that was never tidied, a design that suited the product two years ago, a library three versions behind. Every codebase has some. The useful question is not how to eliminate it, which is neither possible nor sensible, but which parts to deal with and when.
Why the metaphor fits
Like financial debt, a shortcut lets you have something sooner, and you pay interest afterwards. The interest is the extra time every later change takes because of it. Some debt is taken on deliberately, to meet a date, and that can be a sound decision. Trouble comes when nobody tracks it and the interest quietly consumes most of the team's time.
Interest depends on where the debt sits
A badly written module that nobody has touched for three years costs nothing. It works, and it is left alone. The same quality of code in the part of the system that changes every week costs time on every single task.
So judge each problem on two things: how bad it is, and how often the team has to work in or around it. Version control history shows which files change most. Debt in those files is the expensive kind.
Fix now
- Security problems. Outdated components with known vulnerabilities, weak handling of passwords or personal data.
- Risk of data loss. Missing or untested backups, operations that can corrupt records.
- Whatever blocks the next planned work. If the roadmap needs changes to an area that is too fragile to change, repair it first.
- Things that slow every change. A test suite that takes an hour, a deployment that needs a day of manual steps.
Contain
Some areas are poor and too large to rewrite soon. Contain them. Put a clear boundary around the old part so that new code talks to it through one well-defined interface. Add tests that record its current behaviour, so that changes elsewhere cannot break it unnoticed. Then leave it until there is a business reason to replace it.
Leave
Code that is ugly, stable and rarely touched can stay as it is. So can anything in a part of the product that is due to be retired. Disagreements about style and patterns that are a matter of taste are not debt at all. Rewriting working code for elegance spends money and adds risk for no return.
Make it visible
Keep a short list of known debt items. For each, note where it is, what it costs in practice, and roughly what fixing it would take. Describe the cost in terms the business recognises: "every change to pricing takes three extra days and has caused two incidents this year" is something a budget holder can weigh. "The code needs refactoring" is not.
Pay it down steadily
The approach that works is a regular, modest allowance. Many teams reserve a share of each work cycle for improvement, and they tidy the area they are already changing for a feature. This keeps the interest from growing without stopping product work.
What rarely works is halting everything for a large clean-up project. It delivers nothing visible for months, it is hard to finish, and it is the first thing cancelled when a deadline approaches.
The rewrite question
Starting again from scratch is tempting and usually a mistake. The old system contains years of fixes for situations nobody remembers, and a rewrite has to rediscover each one. Replacing the system piece by piece, while it keeps running, takes longer on paper and succeeds far more often. A full rewrite is justified in narrow cases, for example when the underlying platform is no longer supported at all.
Signs the debt has become urgent
- Small changes regularly take much longer than anyone expects.
- Fixing one thing breaks another.
- Releases are feared and happen rarely.
- New engineers need months to become productive.
- Only one person dares to touch certain parts.
Summary
Deal with debt that is dangerous or that sits where the team works every day. Contain what is large and stable, leave what is harmless, and reserve regular time so it does not build up. Assessing an existing codebase this way is a common start to our custom software development work. If your team is slowing down and you are not sure why, we can take a look.