When technical debt is worth the effort

The advice here is unglamorous, which is probably why it gets skipped. Technical debt is not free, and pretending otherwise leads to bad decisions.

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.

When it is worth it

Some debt is a deliberate trade, some is just neglect. Getting it slightly wrong is survivable. Ignoring it entirely is not. Doing this properly once is usually cheaper than doing it approximately three times.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. There is a version of this that is over-engineered, and it is worth avoiding.

How to decide

Paying a little down each cycle beats a rewrite. The cost of getting this wrong is rarely visible on the day it happens. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

How to tell if yours is fine

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
• Track it in writing or it becomes invisible — and you know whether that is true here
• There is a way to tell whether the last change to this helped

Pick the one that would hurt most if it failed, and start there.