Technical debt, explained without the jargon

Teams tend to reach for this after something has already gone wrong. Here is technical debt without the vocabulary that usually surrounds it.

Most development decisions are really maintenance decisions wearing a different hat. If two people in the business would answer this differently, that gap is the actual problem.

The short version

Some debt is a deliberate trade, some is just neglect. This is the sort of thing that compounds, quietly, in both directions. Budget a little time for it every quarter and it never becomes a project of its own.

Why people complicate it

Most of the confusion comes from tooling rather than from the idea itself. The reasoning matters more than the rule, because the rule has exceptions.

Track it in writing or it becomes invisible. That sounds obvious written down. It is still the thing most often skipped. It is worth deciding this deliberately rather than inheriting whatever the last person set up.

Making it stick

Paying a little down each cycle beats a rewrite. That sounds obvious written down. It is still the thing most often skipped. Budget a little time for it every quarter and it never becomes a project of its own.

In practice

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Three things worth confirming about technical debt before you move on:

• Someone can say what the current setup is without going to look
• Some debt is a deliberate trade, some is just neglect — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If any of that sounds like a description of your current setup, it is fixable.