You know that feeling when you open a file, see the spaghetti, and immediately want to nuke it from orbit? Yeah, stop doing that.
Every developer has been there. You inherit a codebase that looks like it was written by a sleep-deprived intern at 3 AM. Your first instinct? Rewrite. Clean slate. Start fresh.
Rewrites are where codebases go to die.
Here’s why: you can’t stop the world while you rebuild. Features still need shipping. Bugs still need fixing. Your “quick rewrite” becomes a six-month death march where half the team forgets what the old code did, the other half can’t agree on what the new code should do, and nobody remembers why that weird hack on line 847 exists — until removing it breaks production.
I’ve seen this firsthand. A team decides to “modernize” their authentication layer. Three months later, they’ve got two auth systems running in parallel, neither fully working, and the original developer who wrote the old one has left the company. The rewrite becomes the new legacy code.
So what’s the alternative?
It’s called accretive editing. And it flips everything you think you know about cleaning up code.
The best way to kill bad code isn’t deleting it — it’s making it irrelevant.
Think of it like gentrification, but for code. You don’t bulldoze the bad neighborhood. You build something better right next to it. Then something better next to that. Slowly, the old code becomes a ghost town. Nobody calls it. Nobody needs it. It just sits there, harmless, until one day you delete it and nobody even notices.
Here’s what this looks like in practice.
You’ve got a 500-line function that handles user registration. It’s a monster. It validates input, creates the user, sends a welcome email, logs analytics, and handles three different payment providers — all in one function.
The rewrite instinct says: “I’ll tear this apart and build a clean service layer.”
The accretive instinct says: “I’ll write one new function that handles just the email part. Next sprint, I’ll write one that handles just the payment part. Each time, I redirect a small piece of the old function to the new one.”
Six months later, that 500-line monster? It’s three lines calling three clean services. You didn’t rewrite anything. You accreted your way out of the mess.
Every safe change you ship today is worth ten perfect changes you’ll ship never.
The beauty of this approach is that each step is reversible. Each step is testable. Each step can be deployed without fear. You’re not betting the company on a big bang — you’re placing small, safe bets that compound.
But here’s the part that makes developers uncomfortable: you have to live with the ugly code for a while. You have to tolerate imperfection. You have to accept that the old code will sit there, stinking up the place, until the new code makes it irrelevant.
That’s hard for people who care about craftsmanship. It feels like leaving trash on the floor.
Tolerance for imperfection isn’t laziness — it’s the price of continuous progress.
The alternative is what most teams actually do: they plan the rewrite, argue about the rewrite, start the rewrite, abandon the rewrite, and live with the original code anyway — plus all the half-finished rewrite code piled on top.
Accretive editing isn’t about being lazy. It’s about being honest. It acknowledges that codebases are living systems, not architectural blueprints. You can’t pause a living system while you redesign it. You have to improve it while it’s still running, like rebuilding an airplane mid-flight.
The next time you’re staring at a mess of code and feeling the urge to rewrite, ask yourself one question: what’s the smallest piece of good code I can add today that makes a piece of bad code irrelevant tomorrow?
Do that. Then do it again. Then again.
The code you’re afraid to touch isn’t your enemy. The rewrite you never finish is.
FAQ
Q: Doesn't this just leave dead code lying around forever?
A: Only if you're lazy about the cleanup phase. The whole point is that the old code becomes irrelevant first, THEN you delete it. You're not avoiding cleanup — you're sequencing it so it's safe. Dead code that nothing calls is harmless. Half-finished rewrites that break production are not.
Q: How is this different from just normal incremental refactoring?
A: Traditional refactoring often focuses on modifying existing code in place — extracting methods, renaming variables, simplifying conditionals. Accretive editing is specifically about ADDING new code alongside the old, then redirecting to it. You never touch the bad code until it's already orphaned. The risk profile is completely different.
Q: Isn't this just an excuse to never do the hard work of a proper rewrite?
A: The 'proper rewrite' is a myth that kills projects. The hard work isn't in the rewrite — it's in the discipline of making small, safe, continuous improvements. Accretive editing is harder than rewriting because it requires patience and strategic sequencing. Rewriting is the lazy option disguised as ambition.