Refactoring vs. Rewriting Your Code: What’s the Best Choice?

To refactor or rewrite? It’s a question that has plagued developers for years.

There’s good reason to think carefully about it: choosing the wrong option can mean creating a new application version that’s buggy, incompatible with new tech, confusing to new developers, or even flat-out broken.

Generally speaking, I err on the side of the classic adage: “If it ain’t broke, don’t fix it.” This is to say that rewriting carries a much higher risk and should be avoided when possible.

But this doesn’t always apply. And unfortunately, there’s no silver bullet rubric for choosing between refactoring and rewriting. You’ll need to look at each project individually and what you’re working with to determine the most promising option.

Let’s make a case for each, and look at some scenarios where one option notably outweighs the other.

The case for refactoring: Incremental improvements with less risk

Refactoring is the practice of changing the internal structure of the code without changing its external functionality. You can think of it like remodeling a home, where you’re updating only the area that needs to be improved while leaving the rest intact.

It’s a foundational practice for any development team — a go-to way to improve software on a continuous basis, like fixing bugs or issues and generally improving its structure, maintainability, readability, and functionality.

With refactoring, these updates are made as smaller, incremental changes. It allows us to wrap old code into new frameworks and then write the new functionality in the new framework. This helps to isolate changes and avoid risks like introducing new bugs or breaking the original code. This is a huge consideration when you have a legacy system with an established user base.

APIs are a great use case for code refactoring. Say you have an old API that’s all JSON and JavaScript based, but you’re creating something in web services which sends out XML. You can refactor it by reusing those web services that pump out XML and pushing them to JSON.

In a sense, you’re combining the old and the new. And that’s the glory of refactoring.

When to refactor your code

Here are some general scenarios for when you might benefit most from refactoring instead of rewriting.

1. You’re making incremental improvements. Refactoring is typically the best route when you’re making smaller, incremental changes. This way, you can maintain the core functionality while enhancing the code’s performance and maintainability.
2. You’re integrating new features and tech. Because refactoring lets you update and expand your application without the need for a ground-up rewrite, it’s ideal for integrating new features and tech into an existing system.
3. You want to minimize and mitigate risk. Why compromise stability and reliability? Refactoring lets you address issues and improve your code while keeping the known, functioning parts intact.

The case for rewriting: Break in case of fire

You know how fire extinguishers are kept in small windows with a sign that says: “In case of fire break glass”?

Well, that’s how I feel about rewriting.

It should be a last-ditch solution for when the existing code and software is metaphorically on fire. It’s so far gone that it’s not worth your time and effort to try to save it, so it’s best to break it and start over.

But the tough part is determining if it’s truly on fire. Say you’re working with a system that’s five years old and it already has a big user base. You can count on the fact that many of those extra lines of code in there are serving a purpose. They’ve likely been added in over the course of those five years to do things like fix bugs and address end-user issues.

Deleting those lines could be catastrophic for the application’s functionality if you’re not sure of the reason and implications for every single one.

But that’s not to say that rewriting can’t work. Sometimes it works really well. Let’s look at some of those cases now.

When to rewrite your code

Here are some general guidelines for when you need rewriting instead of just code restructuring:

1. You’re doing a full redesign. Starting from scratch makes sense when you want a complete overhaul of branding and styling, for example. You’ll be sure that the new application works well with your vision.
2. The old tech is obsolete. If the tech stack is so outdated that it’s basically impossible to upgrade or maintain, you might need to toss it. This is especially true if it’s so old that there’s no support for the old platform.
3. New functionality is most important. If you want to create new functionality, and the proportion of that new functionality outweighs the existing functionality, rewriting may be the way to go.
4. The old code is just really bad. Sometimes we encounter tech that’s been written so badly that we can’t upgrade the code and write wrappers around it. If you can’t salvage it, rewriting is the only option.

Consider carefully before taking the leap

A rewrite is a big deal. That’s why you should really take the time to analyze the existing code, what you’re looking to accomplish, and what it will take to get from point A to point B. Many people tend to think that a rewrite is a lot easier and a lot lower-stakes than it actually is — and those people sometimes feel the burn of their hasty decisions.

If you’re unsure which route to take for your development project, it’s always a good idea to consult a professional developer or agency. They’ll be able to take a look under the hood and figure out the best path forward for your software.