Why you should rewrite your entire codebase

Program in a team environment for long enough and you'll eventually find yourself asking the forbidden question:

Should we just rewrite this mess and start from scratch?

I think its a valid question and a noble one at that. You care deeply enough about the success of the project that you are willing to start from nothing in the hopes that you might come out the other side with something better. However, convincing management that a rewrite is necessary almost always becomes an insurmountable task -- a battle you can never win. They'll say that it takes too much investment in the form of time and money, and it works well enough now, so why bother? And they probably are right. Regardless, it becomes natural to ask: "Ok, fine. But when should you rewrite your codebase?" Poke around enough reddit threads, and hackernews forums and you'll always get the same answer:

Never

And while I agree for the most part, I think its a useful thought exercise to consider why you, in fact, should rewrite the codebase; and not for the typical reasons one might think like, "oh its so messy", or "it will reduce development time on new features." Neither of those are actually good arguments to make to management because they are extremely hard, nay, impossible to quantify. Its a blurry metric. However, if you have made it all the way here and are still convinced that you should face the fire and ask to do a rewrite, here are my three actually good arguments for rewriting a codebase. It starts with morale.

It will increase team morale

Developers want to work on projects they’re proud of. Giving the team an opportunity to rewrite a messy codebase allows them to create something elegant and performant, reigniting a sense of ownership and pride. Maintaining a tangled, legacy codebase can wear developers down over time. They spend more time fixing bugs and refactoring than building new features, leading to a lack of excitement and innovation. Starting fresh creates a shared goal, and the rewrite project can bring the team together to solve complex problems collaboratively. It’s an opportunity to foster deeper investment in the codebase and each other’s growth.

We've all been there: why do I need to work on my actual job, versus hacking away some more at my side-project that I'll probably never finish? There is pride, ownership, and excitment in that side-project. A re-write can establish those same feelings.

It attracts young, new talent

Recruiting young talent can help create a diverse and inclusive workplace. It helps organizations remain competitive by ensuring they have the necessary talent and skills to adapt to changing market conditions. But how do you attract this talent? Hint: its not by sticking with Java SE 8.

Instead, you need to demonstrate that you’re embracing new technologies, modern frameworks, and a culture of continuous learning. The best young talent wants to be part of a team where they can learn, grow, and make an impact with the latest and greatest tools. Offering the opportunity to work on a freshly rewritten codebase using cutting-edge tech stacks like Rust, TypeScript, or cloud-native platforms can be a huge draw. It signals that you’re not just paying lip service to innovation but are actually invested in it.

So, if you want to attract bright, young engineers, start by asking yourself: “Is our codebase a playground for innovation or a minefield of technical debt?” If it’s the latter, a rewrite might just be the key to turning your company into a talent magnet.

It forces you to try new things

Perhaps most importantly, a complete re-write might force you to try new things. I've always said the best programming language for any problem is the one that lets you solve the problem the fastest. And while still true, I think there's merit in trying something new, for the sake of trying something new; especially when deadlines are not an issue.

If you've ever watched Avatar: the last Airbender, my favorite quote from Uncle Iroh goes like this:

It is important to draw wisdom from many different places. If we take it from only one place, it becomes rigid and stale. Understanding others, the other elements, and the other nations, will help you become whole... It can make you more powerful.

I think the same is true for programming.

By sticking to only one technology stack or design pattern, you’re limiting your ability to think creatively and solve problems effectively. Every programming language, framework, or architectural style offers unique perspectives on problem-solving. Exploring these different “elements” can make you a more well-rounded developer, capable of approaching challenges from multiple angles.

Even if, in the end, you decide to stick with the tools and technologies you know, you’ll come away with a deeper understanding of why they’re the right choice. In the same way that Uncle Iroh emphasizes the value of understanding all elements, exploring new technologies—even just once—can make you a more versatile, adaptable, and ultimately better developer.

Conclusion

The reality is that codebases, like teams and companies, are living entities. They evolve, grow, and sometimes outgrow their original designs. A rewrite doesn’t just provide an escape from technical debt—it’s a chance to realign the product and team with modern needs, ambitions, and values.

So the next time you find yourself hesitating to propose that forbidden question, remember: it’s not about discarding the old for the sake of the new. It’s about creating something that the entire team can rally behind and feel proud of. If that means taking on the monumental task of a rewrite, then do it for the right reasons, with a clear vision in mind, and a plan to bring the team along for the journey. Because in the end, rewriting a codebase isn’t just about writing better code—it’s about building a better team, product, and organization.