A practical checklist for technical debt

The gap between knowing this and actually doing it is where most teams lose ground. Run through this the next time technical debt comes up.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. The practical test is whether someone new to the project could tell, in a minute, that it had been handled.

The checklist

• Some debt is a deliberate trade, some is just neglect
• Track it in writing or it becomes invisible
• Paying a little down each cycle beats a rewrite
• Someone is named as the owner
• There is a date to review it again

What it costs to ignore

Some debt is a deliberate trade, some is just neglect. Small and consistent beats large and occasional here. Doing this properly once is usually cheaper than doing it approximately three times.

The short version

Most development decisions are really maintenance decisions wearing a different hat. 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

Worth checking on your own setup before it becomes someone else's problem to fix.