A production issue appears at 4:52 PM on a Friday.
Customers are affected. Alerts are firing. Leadership wants updates. Nobody has time for a perfect solution.
Someone suggests a workaround.
"Let's patch it for now. We'll clean it up next sprint."
Everyone agrees.
The patch goes live.
The incident ends.
The team moves on.
And that's usually the moment a temporary fix begins its journey toward becoming permanent infrastructure.
Most engineers assume technical debt is created by poor engineering decisions.
In reality, some of the most stubborn technical debt starts as a completely reasonable decision made under pressure.
The quick fix wasn't reckless.
It was practical.
It solved the immediate problem, reduced business impact, and allowed everyone to sleep that night.
The problem is what happens afterward.
Nothing.
The next sprint arrives, but priorities change.
A customer request becomes urgent.
A new feature gets scheduled.
Another production issue appears.
The cleanup task quietly slips into the backlog.
Then it slips again.
And again.
Eventually, nobody talks about it anymore.
The workaround survives long enough to become part of the system.
This is where software systems develop a strange kind of organizational memory.
New engineers join the team and see the workaround already in place.
To them, it isn't a workaround.
It's simply how the system works.
Documentation starts referencing it.
Monitoring dashboards depend on it.
Other services integrate with it.
New features are built around its behavior.
Without anyone making a conscious decision, a temporary patch becomes a core dependency.
The most dangerous part is that quick fixes rarely create immediate problems.
If they constantly broke production, teams would remove them quickly.
Instead, they usually work.
Not perfectly.
Not elegantly.
But well enough.
And "well enough" is often all a system needs to survive for years.
The temporary script created for a one-time migration becomes part of every deployment.
The emergency API endpoint becomes a business-critical integration.
The shortcut database field becomes essential for reporting.
What was once considered technical debt slowly transforms into infrastructure.
Years later, someone finally proposes removing it.
The response is almost always the same.
"Are we sure nothing depends on it?"
Nobody knows.
The engineer who created it left two years ago.
The original ticket is long gone.
The documentation is incomplete.
And after years of integrations, assumptions, and hidden dependencies, removing the fix suddenly feels riskier than keeping it.
So it stays.
Not because anyone believes it's the right solution.
Because nobody can confidently prove it's safe to delete.
The irony is that quick fixes are not the enemy.
Every engineering team needs them occasionally.
Production incidents don't wait for perfect architecture.
The real mistake isn't creating a shortcut.
It's failing to assign an expiration date to it.
Because software has a habit of preserving yesterday's compromises long after everyone forgets why they were made.
And if a temporary solution survives long enough, it stops being temporary.
It becomes the system.
The next time you hear someone say, "We'll fix it properly later," remember:
Later is where most core dependencies come from.
Top comments (0)