Five mistakes teams make with technical debt

Every audit we run turns up some version of this. These are the ones we run into repeatedly when we audit technical debt.

Most development decisions are really maintenance decisions wearing a different hat. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Common failure modes

• Treating it as a launch task rather than an ongoing one
• Assuming someone else already owns it
• Some debt is a deliberate trade, some is just neglect
• Track it in writing or it becomes invisible
• Never checking whether the fix actually worked

Paying a little down each cycle beats a rewrite. Small and consistent beats large and occasional here. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Where to go from here

How to tell if yours is fine

The question is rarely whether something can be built, but what it costs to keep running afterwards. Three things worth confirming about technical debt before you move on:

• Someone can say what the current setup is without going to look
• Paying a little down each cycle beats a rewrite — and you know whether that is true here
• There is a way to tell whether the last change to this helped

None of this needs a rewrite. Most of it is a morning's work once someone decides to do it.