It is almost a law of software: bring in a new developer or team, and within days they will suggest rewriting what exists. Sometimes they are right. Often it is the most expensive possible reaction to a fixable problem. Here is how to navigate it.
The short answer
New teams want to rewrite mostly because they cannot understand the existing code, so reverse-engineering it feels slower than starting fresh. Some rewrites are justified; many are not. You prevent the avoidable ones by handing over documented, runnable, well-structured code in the first place.
Why it happens
- They can't understand it. With no documentation and tangled structure, figuring out someone else's code can genuinely take longer than rewriting, so they propose the rewrite.
- It is more fun. Greenfield code is more enjoyable than learning a stranger's.
- It shifts blame. "It was a mess, so we rebuilt it" is a tidy story if things go wrong.
- Sometimes it is real. Occasionally the foundation truly is broken or insecure.
When it is legitimate vs not
Ask for specifics. A justified rewrite comes with concrete reasons: a fundamentally insecure design, an unscalable architecture, a dead technology. An unjustified one comes with vibes: "it's messy," "I don't like how it's done." Messy-but-working code is usually cheaper to learn and improve than to rebuild.
How to stop the cycle
The rewrite urge is mostly a symptom of a bad handoff. Prevent it at the source:
- Documentation. So a new team can understand without reverse-engineering (see what documentation you need).
- A runnable codebase. If it runs on day one, trust starts high.
- A clean architecture. Sound structure is worth keeping, not replacing.
- A walkthrough. A short knowledge transfer answers the "why" that code alone cannot.
When those exist, "we should rewrite it" gets replaced with "we can start shipping changes this week."
Build it right the first time
The cheapest rewrite is the one you never need. A product simulation is built to be picked up: documented, runnable, and well-architected, so the next team extends it instead of demanding to start over (and you avoid paying twice).
Want a foundation teams build on, not replace? Start a project.
Frequently asked
Is the urge to rewrite ever legitimate?
Sometimes. If the existing code is genuinely broken, insecure, or built on a dead-end foundation, a rewrite can be the right call. But it is proposed far more often than it is actually justified, usually because the new team simply cannot understand what exists.
How do I tell a real rewrite need from an avoidable one?
Ask the team to point to specific, concrete problems, not just 'it's messy.' If they cannot, the issue is usually understanding, which documentation and a walkthrough fix far more cheaply than a rewrite.