If you’ve spent any time writing software, you’ve probably felt the urge. You open a codebase you haven't touched in a year, or one written by someone else, and your first reaction is a mild sense of horror. The architecture is convoluted, the variables are named poorly, and the dependencies are a tangled web.
Your immediate thought is: It would be faster to rewrite this from scratch.
It’s a seductive idea. Starting over feels like stepping out of a dark, cluttered basement into a bright, clean room. You think about how much faster you could write it now that you understand the problem. You picture the clean lines, the elegant abstractions, the perfect tests.
But in almost every case, this urge is a trap.
The primary reason rewrites are so appealing is that the first ninety percent of a project is incredibly fun. When you start with a blank editor, you have total freedom. You don't have to worry about backwards compatibility. You don't have to support weird edge cases. You don't have to integration-test with legacy systems.
For the first few weeks of a rewrite, you feel like a genius. Your velocity is off the charts. You think, See? I told you we should have done this months ago.
But then you hit the last ten percent.
The last ten percent is where the real world lives. The old, messy codebase wasn't messy because its creators were stupid. It was messy because it had to survive contact with reality. That weird if statement on line 412 that makes no sense? It exists because a specific client’s database returns dates in a non-standard format on Tuesdays. That convoluted caching logic? It’s there to prevent the server from crashing when a search engine scrapes the site.
When you rewrite from scratch, you have to rediscover all of those edge cases. And you usually rediscover them the hard way: by breaking things for your users. By the time you’ve added all the patches, workarounds, and hacks necessary to make the new system actually work in production, it is often just as messy as the old one. Except now, you’ve spent six months building something you already had.
The Second System Effect
There is a secondary danger to starting fresh: the second system effect. When you are forced to work within the constraints of an existing system, you have to be disciplined about what you add. But when you start a new system, all those constraints vanish.
You decide that you won’t just rebuild the original application. You will also build a better plugin system, a cleaner database abstraction layer, and a more modern build pipeline. Because you have a clean slate, you feel you have the license to build it "right" this time.
The rewrite, which was supposed to take two months, balloons into a multi-year project to build a platform that does everything. Netscape famously fell into this trap in the late nineties when they decided to rewrite their browser from scratch. It took them three years to ship. By the time they finished, Microsoft's Internet Explorer had already won the browser wars, and Netscape was dead.
Why We Want to Rewrite
If rewrites are so dangerous, why do developers constantly want to do them?
I think it’s because reading code is harder than writing it.
Writing code is a creative act. You are building something out of nothing. Reading code, especially messy code written by someone else, is a cognitive chore. It requires you to load another person's messy mental model into your own head. It’s tiring, frustrating, and often boring.
When we look at a messy codebase, our brain registers the cognitive pain of having to understand it. The proposal to "rewrite it" is actually an escape mechanism. It’s procrastination disguised as engineering. It allows us to trade the boring, hard work of reading and refactoring for the fun, easy work of writing something new.
Of course, there are times when a rewrite is actually justified. If the underlying technology stack is obsolete, or if the core business model has changed so fundamentally that the old code is solving the wrong problem, you might have to start over.
Refactoring in Place
But these cases are rare. Most of the time, the right path is the boring one: incremental improvement.
If you want a clean codebase, you shouldn't wait for a clean slate. You should change the wheels while the car is moving. In practice, this means refactoring in place.
You identify a messy subsystem, isolate it behind a clean interface, and slowly rewrite the internals without changing how the rest of the application interacts with it. This is harder to do than writing a new system from scratch because it requires surgical precision. You have to understand both the old mess and the new structure at the same time. But it is the only way to improve software without stopping the business.
When you do this, you also gain a deeper understanding of why the old code was written the way it was. You find the edge cases and the weird workarounds, and you preserve them in the new implementation. You are building on top of the historical lessons of the project, rather than throwing them away.
You don't need a clean slate to write clean code. You just need the discipline to leave every file you touch slightly better than you found it. If you refactor one function a day, the codebase will eventually become clean, and it will happen while the system is still running and serving users.
This isn't just true of software. We do the same thing in other parts of life. We want to start a new diet plan rather than eating slightly better today. We want to pivot to a brand new career rather than fixing the problems in our current one. We want to buy a new productivity app instead of just doing the work.
A clean slate is a fantasy. It promises that we can escape our past mistakes without having to clean them up. But the mess has a way of following us. The only way to get a clean house is to start sweeping.