Why "temporary" fixes become permanent — and how to stop it
The hotfix that's still running eighteen months later.
Every codebase has one: a workaround shipped under pressure, labeled temporary, that's still running years later because it works well enough and nobody wants to touch it. The problem isn't that temporary fixes exist — sometimes they're the right call. The problem is they're invisible once they stop being urgent.
There's no forcing function
Temporary fixes become permanent because there's no forcing function to revisit them. The deadline that justified the shortcut is long gone, but nothing on the calendar ever says "come back to this." It just quietly becomes load-bearing infrastructure nobody chose on purpose.
Make the shortcut visible, not invisible
A comment in the code rarely gets seen by the people who'd act on it. A ticket, tracked alongside real work with an owner assigned, at least has a chance of surfacing again — the goal is making the debt visible to planning, not just visible to whoever happens to open that file.
A real date, not "someday"
The fix is procedural, not technical: every shortcut gets a ticket, an owner, and a real date to revisit it — not "someday," an actual sprint. If it's genuinely fine to leave as-is, that's a decision made consciously, not a fact discovered by accident three years later.
- Temporary fixes persist because nothing forces a second look.
- Give every shortcut a ticket, an owner and a real revisit date.
- Leaving a fix in place should be a conscious decision, not an accident.
Feature flags: the quiet infrastructure behind confident releases
HAVE A PRODUCT IN MIND?
Tell us what you're building and where you need engineering support.