Getting started with technical debt
The version of this that works is simpler than the version most people imagine. A short on-ramp to technical debt for teams who have not touched it before.
Most development decisions are really maintenance decisions wearing a different hat. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.
What it costs to ignore
Some debt is a deliberate trade, some is just neglect. That sounds obvious written down. It is still the thing most often skipped. Check it against what you would want a competitor's site to get wrong.
Your first week
- Find out what is already in place
- Track it in writing or it becomes invisible
- Change one thing and measure it
Paying a little down each cycle beats a rewrite. Where this goes wrong is almost never a lack of knowledge. Budget a little time for it every quarter and it never becomes a project of its own.
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
- 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
The point is not perfection, it is knowing which of these you have consciously chosen to skip.