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.
You May Also Like
What Tinder🔥 taught me about bad Dataverse design
Toxic Tinder traits meet Power Platform red flags in this brutally honest (and slightly hilarious) guide to what not to build.
Stop pretending your text is bold: why fake formatting breaks accessibility
Faking bold text with Unicode might make your post stand out — but it breaks screen readers, ruins searchability, and creates compliance risks. This blog breaks down why formatting tricks do more harm …
Copilot Studio: Part 1 – when automation bites back – autonomy ≠ chaos
Most organizations fear agent autonomy; not because the system is too smart, but because no one’s defined what happens when it’s wrong. This post explores how to design autonomy with clarity, …