Technical Debt: Which Parts to Pay Down and Which to Ignore
Not all technical debt should be repaid. The skill is telling which debt charges interest and which is simply old code that works.
Developers ask for time to clean things up; the business hears a cost with no visible benefit and defers it. Both sides are partly right, and the argument recurs quarterly because neither has a shared way to tell which debt actually matters.
Debt that charges interest
- Anything that makes every future change slower — a tangled data model, duplicated logic in five places, no test coverage on the parts that break.
- Dependencies no longer receiving security updates. This is not a preference; it is an unpatched liability with a public list of known holes.
- Knowledge concentrated in one person, which is debt even when the code is good.
- Manual deployment or recovery steps, which are fine until the person who knows them is unavailable during an incident.
Debt that does not
Old-fashioned code that works, is rarely touched and has clear boundaries is not a problem worth funding. Neither is a framework version behind the latest, absent security implications. Debt only costs you when you have to work near it — code you never touch charges no interest, however unfashionable it looks in a review. It is also our own definition of done, written out in what well-built means.
Funding it without a rewrite
- Allocate a standing percentage of capacity — commonly ten to twenty percent — rather than requesting a dedicated project that will always lose to a feature.
- Pay debt down where you are already working. Cleaning code you are about to change is nearly free; cleaning code nobody touches is a hobby.
- Quantify it in delivery terms: 'this change took three days instead of one because of X'. Repeated three times, that becomes a business case a non-technical person can act on.
- Never propose a full rewrite. Rewrites take longer than estimated, deliver no new value during the process, and frequently reproduce the original problems with newer tools.
- 10-20% of capacity as a standing allocation
- 0 full rewrites proposed
- 1 question: does it slow us down
Frequently asked questions
How do we explain technical debt to a non-technical stakeholder?
In delivery time, not code quality. 'Features in this area take three times longer, and here are three examples from last quarter' lands where 'the architecture is poor' does not.
Is a rewrite ever justified?
Rarely, and usually only when the platform itself is unsupported or the business model has changed so fundamentally that the data model no longer describes reality. Incremental replacement — new code alongside old, migrating piece by piece — is almost always the lower-risk path.
More on this topic: Web & Product.
Keep reading
Want this built for your business? See what we do.