The Two-Hour Fix That Lived Forever

Found this in production today:

// TODO: Fix this properly - temporary workaround
// Added: 2023-06-15

The comment was added 2 years, 7 months, and 14 days ago.

The developer who wrote it? That was me.

The bug it was working around? Fixed 6 months later in a completely different file.

The code itself? Still running. Still working. Still "temporary."

The Lies We Tell Ourselves

We've all been there. The deadline is breathing down your neck, the bug is weird, and you just need to make it work. So you do what any reasonable developer would do:

You write a temporary fix.

And you tell yourself one of these stories:

"I'll fix this tomorrow."

Spoiler: You won't. Tomorrow has its own fires, its own deadlines, its own temporary fixes.

"This is just for the demo."

Cool story. But the demo became the product, the product shipped, and now your hack is handling payment transactions.

"Let me get it working first, then I'll clean it up."

This is the most dangerous lie because it sounds responsible. Like there's some future version of you with infinite time and motivation who will come back and refactor this mess.

"Technical debt is fine, we're moving fast."

Are you? Or are you just moving in circles, patching the same systems you broke last sprint?

The Signs Your "Temp" Is Now "Perm"

Here's a quick diagnostic. If any of these sound familiar, your temporary code has achieved permanent residency:

Your TODO comment has achieved legal drinking age
New devs are told "don't touch that file, nobody knows how it works"
It has its own helper functions (which are also temporary)
You're now writing temporary code on top of your temporary code (temporary-ception)
The variable is literally named $temp, $hack, or $please_delete
There's a comment explaining what the code does instead of the code just doing it
You're afraid to run tests because they might expose the thing you've been ignoring

If you checked zero boxes, you're either lying or you've never worked in production.

A Framework for Temporary Code

Look, I'm not here to tell you to never write temporary code. That's unrealistic. Sometimes you need to ship now. Sometimes the "perfect" solution takes two weeks and the hack takes twenty minutes.

The problem isn't temporary code. The problem is unexamined temporary code.

Here's a simple framework. Next time you're about to write a quick fix, ask yourself:

Question 1: Will this be deployed to production?

YES → It's not temporary anymore. Write it properly.

NO → Put a literal expiration date. And I mean a calendar date, not "someday."

// TEMPORARY: Expires 2026-03-01
// Issue: https://github.com/cekapcoder/site/issues/237
// Why: Quick fix for holiday sale, will refactor inventory system after

Question 2: Will this affect user data?

YES → Not temporary. No exceptions. Data corruption is forever.

NO → You get 48 hours. Document it in your issue tracker before you commit.

Question 3: Is there already an open issue to fix this?

YES → Link to it in the code. Make it impossible to ignore.

NO → Create one NOW. Title it "[URGENT] Refactor temporary hack in [file]" before you write another line.

The uncomfortable truth

Here's the thing: Sometimes, a temporary fix is the right answer.

A prototype that validates a hypothesis? Good temporary code.

A workaround for a third-party bug that's blocking your launch? Pragmatic temporary code.

A hotfix at 2 AM to restore service? Heroic temporary code.

The difference between responsible shortcuts and technical suicide comes down to three things:

Intention: You know exactly what you're trading away
Visibility: The whole team can see the debt on the wall
Expiration: There's a calendar date, not a vague "later"

That's not sloppiness. That's strategy.

Real Cekap

Real Cekap isn't about crafting cathedral-perfect code while your competitors ship. It's not about refusing to make tradeoffs.

It's about knowing the difference between:

"I'll fix this eventually" ← A lie

and

"I'm buying 48 hours of velocity at the cost of 4 hours next Tuesday" ← A trade

One is a delusion. The other is a decision.

One lives in production forever, haunting your future self. The other gets paid off on schedule.

Your Turn

Go check your codebase right now. Search for TODO, FIXME, hack, temp, temporary.

Pick one. The oldest one. The one that makes you wince a little.

Either fix it, or delete it, or admit that it's permanent and write it properly.

Your future self will thank you. Probably about 2 years from now.

Code Faster. Build Better. Stay Cekap.