Refactor vs. rewrite: Deciding how to fix problem software
At some point, all developers must decide whether to refactor code or rewrite it. Base this choice on factors such as architectural soundness, time, money and goals.
When application source code becomes unmanageable due to patches, bad maintenance, freewheeling feature additions or other consequences of long operation, developers must either refactor or rewrite.
In a refactor, developers make micro changes to clean up the existing code. With a rewrite, they throw almost everything away, and the coding process essentially starts anew.
Both of these options have advantages and disadvantages. Refactoring code helps to keep it manageable without major overhauls, but might not set the app up for new development technologies or application languages. Rewriting code enables foundational changes to the code, but risks confusing developers or even breaking the product.
Don't think in absolutes for refactoring vs. rewriting code. Instead, determine which one is better for the particular project. This choice depends on factors such as the type of application as well as the team's capabilities, long- and short-term goals for the application, and appetite for risk.
When a programmer refactors software, the goal is to improve the internal structure of the code without altering its external behavior. For example, engineers remove redundant code or break a particularly task-heavy application component into several objects, each with a single responsibility.
Refactoring makes comparatively minor code changes to improve maintainability without changing functionality.
The extreme programming development approach, a concept known as merciless refactoring, stresses the need to continuously refactor code. Theoretically, programmers who refactor continuously make sections of code look better with every change.
Refactored code should be easily understood by other people, so developers can turn code that scares people into code that people can understand and feel comfortable updating on their own.
Advantages of refactoring
Programmers' choice. Refactoring is always an option. The engineers who work on the code don't need anyone's permission to refactor it.
Works for any architecture. You can refactor any software architecture type, from tightly monolithic to massively distributed.
Doesn't duplicate resources. It can improve the quality of the code without slowing down progress. Programmers can refactor while they also move forward with deployment processes. Unlike a rewrite, refactoring does not require developers to maintain two separate codebases.
Low cost. If developers are only working on one part of the codebase, they can choose to clean up only the part they are working on. It does not add a great deal of cost for the business.
Disadvantages of refactoring
Limited reach. While refactoring can improve a piece of code, it cannot fix underlying architecture problems. For instance, code written in Visual Basic 6 is still written in Visual Basic 6 at the end of the refactor.
No new functionality. Because it maintains the status quo of architecture and code, refactoring does not open opportunities to add new functionality into an application.
Requires discipline. Refactoring requires skill, discipline and courage. Programmers who have never been exposed to the complexity of refactoring patterns might be unable or unwilling to dive in. Making these changes is scary without a unit test suite, and programmers unfamiliar with basic refactoring concepts might perceive that it slows them down.
Creates more code to manage. Because it breaks code into smaller chunks, refactoring creates a lot more code to manage and unit test. It changes complex functions into many simpler ones.
When the codebase in question contains hundreds of thousands of lines, it's time to move to the next level: a code rewrite.
The discipline of refactoring is helpful when a system relies on thousands of lines of code. Refactoring breaks that up into abstracted, high-level objects, adds testability to those objects and keeps the functions reasonably small.
However, when the codebase in question contains hundreds of thousands of lines, it's time to move to the next level: a code rewrite.
Advantages and disadvantages of rewriting code
Rather than read and analyze complex, ugly code for refactoring, programmers can opt to just write new code altogether. Unlike refactoring, code rewrites sound relatively straightforward, since the programmers just start over and replace the functionality. However, it isn't nearly that simple.
To successfully rewrite software, engineers should form two teams: one that maintains the old app and another that creates the new one. This means duplicating resources. Worse, the old system is still in production and needs updates to keep it working. As such, the rewrite team must constantly reconfigure plans for the future product to match those changes in the existing one.
Advantages of rewriting
Creates new functionality. One of the benefits of writing code from scratch is that it opens the door for new users, markets, platforms and technologies. For example, rewriting is a way to move client-facing applications from a Windows desktop platform to a web-based or mobile platform. Rewrites eliminate the headache of attempting to retrofit original code to meet demand for different new technologies and application functions.
Enables a fresh start. A rewrite lets new developers instantly implement code they are comfortable with. This advantage is especially attractive after a merger or acquisition. The rewrite creates a new, clean project -- a chance for developers to make their mark or complete a masterwork. It's also a chance to remove technical debt.
Prepares code for emerging technology. Rewrites put the application on a platform that will make it easier to adapt to new development technology and approaches. Rewriting banishes legacy code, which decreases the gap between the existing system and emerging code options.
Disadvantages of rewriting
Time-consuming. Rewrites take time. You're essentially writing new software based on strict requirements. You should only commit to a rewrite if there is plenty of time to rebuild the application's code. As mentioned above, rewrites split resources between a team that manages the original code and a team that creates the new code. The maintenance team might not have sufficient experience with the old code to manage it appropriately.
Can introduce defects. Old code is ugly and can get uglier. To rewrite the software, developers need to examine the old version of the code, find the functions that should remain in the new product and copy them. But another team is maintaining the old application code. In attempts to fix, update and clean the live code, programmers could potentially introduce defects. Those defects require bug fixes to improve performance, and each bug fix makes the code a little bit uglier.
Can result in more unruly code. Rewrites might not solve the problem of ugly code. Using an automated tool to port the application's code to another language is a viable option for rewrites and might save some time. However, using these tools sometimes results in code that is exceptionally hard to read or maintain. The problem arises from an attempt to merge languages together.
How to choose between refactoring and rewriting
Engineering teams should ultimately make the choice to rewrite or refactor based on several factors:
Time. Refactoring is a gradual, incremental process. This makes it suitable for projects with tight deadlines or continuous delivery requirements. Rewriting is a more disruptive, time-intensive process that comes with more drastic changes. Teams will need to work on rewriting the new code while simultaneously maintaining the old codebase. Choose the approach that most closely aligns with the project timeline and the team's experience and risk appetite.
Goals. The organization's long-term goals are a critical consideration. If the goal is simply to improve maintainability, refactoring might be the answer. If the organization aims to support new technologies or reach new markets that the current codebase cannot accommodate, choose a rewrite.
Budget. Budget is also an important factor to consider. Refactoring requires a much lower upfront investment as developers can refactor incrementally while delivering new features. Rewriting demands more financial commitment, as teams need to maintain two codebases simultaneously and potentially wait for new features until the rewrite is finished.
Architecture. The codebase design is also important to consider. If the fundamental architecture is sound, but the implementation is not, teams can restore code quality without starting from scratch. If the architecture has become obsolete, or unable to support modern development or business practices, teams should commit to a rewrite to create the foundation they want.
Refactoring is best for the following:
Projects with limited time and budget constraints.
Applications with sound architecture but messy implementation.
Continuous delivery initiatives.
Rewriting is best for the following:
Applications that need fundamental platform or technology changes.
Projects that need to reach new markets or users.
Projects with the resources to maintain two codebases simultaneously.
Editor's note: This article was updated in 2025 to improve the reader experience.
Matt Heusser is managing director at Excelon Development, where he recruits, trains and conducts software testing and development.
