RibbitSol All articles
Developer Tools

Temporary Forever: How Quick Fixes Turn Into the Architecture You're Stuck With

RibbitSol
Temporary Forever: How Quick Fixes Turn Into the Architecture You're Stuck With

Somewhere in your codebase right now, there's a comment that reads something like // TODO: replace this with a proper solution. It was written in 2021. Nobody has touched it since. The developer who wrote it has since been promoted, changed teams, or moved on entirely — and the 'temporary' fix they left behind is now load-bearing infrastructure.

Welcome to what we at RibbitSol like to call the lily pad problem: the habit of hopping from one quick fix to the next, fully intending to build a proper bridge later, but never quite making it back. Each individual pad seems harmless. String enough of them together and you're not hopping anymore — you're sinking.

Why 'Temporary' Is the Most Dangerous Word in Engineering

The word temporary does something sneaky to the human brain. It creates a mental permission slip. When something is labeled temporary, it bypasses the scrutiny that would normally get applied to a permanent decision. Code review gets lighter. Documentation gets skipped. Testing gets abbreviated. After all, you're going to rip it out soon anyway, right?

Except you're not. And deep down, most engineers know this at the time they're writing the fix. The schedule pressure is real, the deadline is real, and the quick solution is right there. So it ships. And then the next sprint starts, and there's a new set of priorities, and the temporary fix quietly graduates to de facto permanent without anyone signing off on the promotion.

This isn't a failure of individual engineers — it's a failure of how teams account for the work of doing things properly.

The Organizational Blind Spot That Keeps It Happening

Product roadmaps are great at capturing what you're building next. They're terrible at capturing what you need to un-build or re-build. Cleanup work is almost never as exciting to stakeholders as a new feature. It doesn't show up in a demo. It doesn't move a metric in a way that gets celebrated in the all-hands meeting.

So when it comes time to prioritize the backlog, the ticket that says 'replace temporary auth workaround with proper OAuth flow' gets pushed behind 'add dark mode' for the fourth quarter in a row. Not because anyone made a conscious decision that dark mode matters more than security hygiene — but because the cost of not doing the cleanup work is invisible until it suddenly isn't.

This is compounded by what organizational psychologists sometimes call status quo bias: the tendency to leave things as they are because changing them requires effort and carries risk, while leaving them alone feels safe. A working temporary solution, however ugly, is a known quantity. Replacing it introduces uncertainty. Teams rationalize inaction as caution.

The Compounding Interest on Deferred Fixes

Here's where the lily pad metaphor really earns its keep. One temporary fix is a single pad — awkward, but crossable. But temporary fixes attract other temporary fixes. The workaround for your database connection issue spawns a workaround for the timeout it causes, which spawns a workaround for the retry logic that breaks something else downstream. Each new pad makes the original one harder to remove because now something is standing on it.

This is technical debt in its most insidious form — not the kind you deliberately take on as a strategic trade-off, but the kind that accumulates quietly while everyone is looking elsewhere. By the time a team tries to replace the original fix, the effort estimate has ballooned from a two-day project to a multi-sprint initiative requiring three people and a prayer.

And that's when the rationalization really kicks in: it's working, isn't it? Why risk breaking something?

What Actually Works: Making Cleanup Unavoidable

The solution isn't to shame teams into better behavior or to demand that engineers resist deadline pressure through sheer willpower. The solution is structural. Here's what engineering organizations that actually retire their temporary solutions do differently:

Set an expiration date at creation time. When a temporary fix ships, attach a literal deadline to it — not just a TODO comment, but a calendar reminder, a ticket in the backlog with a due date, and ideally a flag in the code that triggers a warning if the fix is still present after that date. Tools like Feature Toggles have popularized this idea for flags; it works just as well for stopgap solutions.

Make the cost visible. Invisible costs don't get prioritized. Create a lightweight 'tech debt register' — a living document or dashboard that tracks known temporary solutions, estimates their ongoing maintenance burden, and makes the accumulated weight of deferred work legible to product and engineering leadership alike. When stakeholders can see that your team spends 15% of its engineering capacity managing workarounds, suddenly cleanup work gets a seat at the table.

Reserve capacity explicitly. Some teams swear by a fixed allocation — say, 20% of every sprint — reserved for paying down debt and retiring temporary solutions. Others do quarterly 'swamp draining' sprints dedicated entirely to cleanup. The specific format matters less than the commitment: cleanup work needs protected time, not leftover time.

Celebrate retirements. This one sounds soft, but it matters. If your team culture only celebrates shipping new things, you'll only ever ship new things. Make a point of acknowledging when a long-running temporary solution finally gets properly replaced. Name it, note it in retrospectives, let the engineer who did the unglamorous work of untangling three years of accumulated hacks get some recognition.

The Swamp Doesn't Have to Win

Every engineering team has a swamp. The goal isn't to pretend it doesn't exist — it's to stop letting it grow while you're busy looking somewhere else. The lily pad problem is solvable, but only if you treat temporary solutions as the liabilities they are from the moment they're created.

At RibbitSol, we're big believers in the idea that great software is as much about what you remove as what you build. The teams that leap furthest aren't the ones who move fastest in the short term — they're the ones who keep their footing solid enough to keep moving for years.

So go find that // TODO comment from 2021. It's time to finally do something about it.

All Articles

Related Articles

Give Engineers a Sandbox or Watch Your Production Burn

Give Engineers a Sandbox or Watch Your Production Burn

Flags Everywhere, Confidence Nowhere: The Hidden Danger of Feature Flag Overload

Flags Everywhere, Confidence Nowhere: The Hidden Danger of Feature Flag Overload

Your Staging Environment Is Lying to You — Here's the Proof

Your Staging Environment Is Lying to You — Here's the Proof