Technical debt for small teams

This is cheap to get right at the start and expensive to retrofit. Most advice about technical debt assumes a team that does not exist at your size. Here is the version that does not.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. It rarely shows up as a line item, which is exactly why it slips.

What to keep

Some debt is a deliberate trade, some is just neglect. Getting it slightly wrong is survivable. Ignoring it entirely is not. It rarely shows up as a line item, which is exactly why it slips.

What to drop

Process that exists to coordinate ten people is overhead when there are two of you. The cost of getting this wrong is rarely visible on the day it happens.

The practical version

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.

In practice

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
• 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

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