What developers actually mean
Technical debt is a shortcut taken deliberately or accidentally that makes future change slower. Hard-coding something that should be configurable, skipping tests, duplicating logic instead of consolidating it.
Like financial debt, it is not automatically bad — borrowing to reach a market first can be an excellent decision. What is bad is not knowing you have it, or paying only the interest indefinitely.
The three kinds, which need different responses
- Deliberate and documented. “We hard-coded this to ship the pilot; we will make it configurable if it survives.” Healthy.
- Accidental. The team learned something and the earlier design is now clearly wrong. Normal, and should be corrected as the area is touched.
- Negligent. No tests, no structure, no documentation, because nobody was allowed the time. This one compounds fastest and is the one to worry about.
How to detect it without reading code
- Estimates growing for similar work. A feature that would have taken a week now takes three.
- Fear of certain areas. “Nobody wants to touch billing” is a debt report.
- Bugs in unrelated places after a change, which means the system has hidden coupling.
- Onboarding time for new developers stretching from days to weeks.
- Releases getting less frequent because each one is frightening.
Ask your team: “if we had two weeks to fix anything, what would you fix and why?” The answer is a debt inventory and it takes ten minutes to collect.
How much to spend paying it down
A commonly used rule of thumb is 15–20% of engineering capacity as ongoing maintenance, adjusted by how fast you are moving. During a hard push it can drop; after one it should rise.
The failure modes are symmetrical. Zero investment produces a codebase where everything is slow and frightening within two years. Excessive investment produces beautiful architecture and no customers.
Pay it down where you are working
Wholesale rewrites are usually the wrong answer: expensive, risky, and they replace known problems with unknown ones. The effective pattern is to improve the areas you are already touching.
Building a feature in the billing module? Add tests to billing while you are there. That way effort follows change, which is where the debt is actually costing you.
Talking about it with the board
“Technical debt” sounds like an engineering indulgence to people who do not write software. Translate it into delivery terms: “features in this area take three times longer than they did a year ago, and two weeks of work would restore most of that speed.”
Framed that way it is a straightforward investment case with a measurable return, which is what it is.