At some point, every system looks outdated.
Messy code.
Legacy decisions.
Workarounds layered over workarounds.
And the idea appears:
rewrite everything from scratch.
Cleaner.
Better.
More modern.
But it almost never happens.
Rewriting means losing what you don’t see
A system is more than its code.
It contains:
- assumptions
- edge cases
- undocumented behavior
- fixes for problems nobody remembers
Most of that isn’t written down.
It’s embedded.
This is exactly the problem described in The Systems Nobody Fully Understands Anymore.
No one fully understands the system.
So no one can fully recreate it.
Behavior is harder to reproduce than code
Writing code is straightforward.
Reproducing behavior is not.
Old systems:
- behave in specific ways
- handle edge cases silently
- include years of fixes
New systems start clean.
Which means:
they also start incomplete.
And the missing parts only show up later.
Change introduces risk — rewriting multiplies it
Every change in a system carries risk.
Rewriting is not a change.
It’s a complete replacement.
Which means:
- everything changes at once
- all assumptions are tested simultaneously
- all hidden dependencies are exposed
This is why failures often look sudden, as described in Why Modern Systems Fail All at Once.
The system doesn’t break gradually.
It collapses.
The system is connected in ways you don’t see
Modern systems are not isolated.
They depend on:
- other services
- APIs
- infrastructure
- user workflows
Changing one part affects everything else.
This is part of what makes infrastructure fragile, as explained in The Fragile Infrastructure Behind “Always Online” Services.
Rewriting doesn’t just replace code.
It rewires dependencies.
Configuration drift makes systems unpredictable
Over time, systems change.
Not through redesign.
Through small adjustments:
- config changes
- patches
- temporary fixes
Individually, they don’t matter.
Together, they redefine the system.
This is exactly what’s described in Configuration Drift: The Silent Killer of Infrastructure.
The current system is not what was originally built.
It’s what it became.
Dependence makes rewriting dangerous
Systems today are not optional.
They are infrastructure.
Payments.
Communication.
Operations.
As described in When Daily Life Depends on Software Infrastructure:
failure is no longer technical.
It’s operational.
Rewriting a system means risking everything that depends on it.
New systems don’t fail less — they fail differently
A rewrite doesn’t remove complexity.
It resets it.
New systems:
- lack historical fixes
- expose new edge cases
- behave in unexpected ways
They don’t inherit old bugs.
They create new ones.
Incremental change beats replacement
That’s why most systems evolve instead of restarting.
- parts are replaced
- behavior is preserved
- risk is distributed over time
It’s slower.
But safer.
What this actually means
The question is not:
“why don’t we rewrite this?”
The real question is:
“what would we lose if we did?”
Software rarely gets rewritten from scratch
not because teams are lazy,
but because systems contain more than code.
They contain history.
And once that history is lost,
it’s almost impossible to rebuild it the same way again.