There are no temporary fixes (just permanent shortcuts)

A while back, I wrote about A hill to die on: there are no tiny changes, just changes we underestimate. If you missed it, give it a read. But there’s a related myth we need to dismantle: “It’s just a temporary fix.”

Ah yes, the sacred chant of backlog triage. We all know how it goes:

“This is just to get us unblocked.”

“Let’s be pragmatic; we’ll clean it up later.”

“We’ll write a proper solution next sprint.”

Spoiler: we won’t.

When did temporary start meaning indefinite?

Once a fix goes live, it’s not temporary; it’s a default. It becomes part of how the system works, how people rely on it, how your future self has to navigate it. That workaround? It’s now someone’s expectation. That duct-taped dependency? It’s in production, baby. Every “just for now” decision is a long-term liability waiting for an excuse to dig in its heels.

We ship intent, not just code

Think about it. That quick-and-dirty fix ships with no expiration date, no conditions, no built-in cleanup plan. And nobody, not the code, not your CI pipeline, not the product owner, is going to magically remember to “circle back”. So it stays. And much like I argued in tiny changes, even the smallest-seeming fix can have wide ripple effects: Unexpected bugs. Fragile dependencies. Future blockers. All because we told ourselves this wasn’t the real solution. But it is. It’s live. It counts.

The real problem: we treat code like a whiteboard

We think we can scribble something quick and erase it later. But software doesn’t work like that. Once it’s deployed, it’s not just code:it’s behavior. It has inertia. It gets integrated into other things. The longer it sits there, the harder it is to untangle. So we end up building systems that are a patchwork of “for now” glued together with hope and good intentions.

What we should say

Instead of calling it a temporary fix, be honest about what you’re doing:

• “This is a compromise with risk”
• “We’re introducing technical debt deliberately”
• “We’re choosing speed over sustainability”

Then, if you go ahead with it:

• Write it down like a bug Don’t hide it behind a TODO; give it an owner and a deadline.
• Make the cost visible. Add it to the roadmap as real work, not invisible hope.
• Flag it in review. Code reviewers should treat “we’ll fix this later” as a blocker unless there’s a plan.

Let’s stop pretending our shortcuts don’t have long-term consequences. If we keep saying “we’ll fix it later” without specifying when and how, we’re not just lying to others, we’re lying to ourselves. You can’t measure what you won’t acknowledge. You can’t clean up what you never wrote down. And you sure as hell can’t call something “temporary” if there’s no plan to remove it.

So the next time you feel the urge to sneak in a fix and promise yourself it’s only for now, just remember:

There are no temporary fixes. Only permanent shortcuts you haven’t regretted yet.