Rebuild or refactor? Should you refactor an existing project and keep improving it or just... rebuild the whole codebase from the ground up? That is the question.
Now, let me take a "lucky guess" and assume that:
- you're facing the challenge of working with legacy code
- the app in question has poorly written code, is unscalable and takes up a lot of memory
- it's a buggy app, with lots of architecture and design issues
- its current features and functionality are rudimentary and/or no longer relevant
So, what should you do now?
Do you refactor just some of the legacy code — which means simply restructuring and reorganizing it, cleaning it up progressively? Or should you take a more "drastic" measure and... start fresh, rewriting the codebase from scratch?
Obviously, there's no one-size-fits-all solution.
Therefore, here are the pros and cons of each approach, as well as a few “hints” on the specific scenarios that favor one over the other.
1. Rebuilding from the Ground Up
What if you got a second chance?
What if you could leverage this opportunity — implement a new powerful technology, let's say — to rebuild the whole system from the ground up?
But this time it would be different:
It would include all those incredible features that you're “fancying” about. It would be lighter, so very scalable and it would run smoother than ever.
Of course, there are cases when rewriting the entire codebase of an existing project is just crucial. The used technology is out of date, the underlying code has got discouragingly… spaghetti-sh during all these years.
And yet, there are a few risks to consider when trying to solve this “rebuild or refactor” dilemma:
- rewrites usually take longer than estimated
- it almost always leads to losing some of the (key) legacy features (unless you will have properly documented them all)
- battle-tested code, business rules and procedures are usually more valuable than fresh new ones
- adopting the very same approach when embarking on a complete rewrite leads to rebuilding roughly the same system
From them all, the “time” factor is the most important one:
By the time you will have rebuilt your software product, the market will have moved on and left you (far) behind.
Yet, if you do decide to start fresh, there are 2 ways of rebuilding your software:
- a complete rebuild, with one migration: basically, on a maintenance day you just move from the old system to the newly rebuilt one
- a gradual replacement/partial re-writes: you break of parts of the codebase, rewrite them and replace them progressively, one by one; this way you get to run multiple checks to ensure you didn't break anything
Word of caution: if your app is actively used, you might want to consider the second method; a whole rebuild would be way too risky...
2. When Is a Full Codebase Rewrite The Answer?
In the “rebuild or refactor” debate there are always specific contexts where rebuilding the whole system is the only answer.
Let me exemplify:
- when you're moving to another platform or language
- when the existing codebase is no longer maintainable: maintaining a 10-20 years old software becomes increasingly expensive (just think how costly and difficult it gets to hire developers that still use those old technologies)
- when the hardware gets (too) old and it gets more and more challenging to find all those frameworks, operating systems, and a new hardware to run your now deprecated software on top of
- when your old system no longer meets your business needs
- when the codebase has got so tangled that maintaining it is a costly and time-consuming burden
The simplest and most effective “formula” to use for solving any code refactoring vs rewriting dilemma is:
Comparing the costs of your existing system's ongoing maintenance and the potential benefits that you'd “ripe” if you rebuilt it from scratch, to the costs of a big rewrite. Is it worth it?
3. Code Refactoring
“If it ain't broken don't fix it.”
Or, better said: there's no need to start anew (which, in many cases, means “breaking it up”) if it works.
Maybe you just need to... improve it. In many cases, refactoring code is not an option because managers and developers aren't familiar with this procedure:
They're unaware of the fact that code could be broken down to multiple independently verifiable chunks.
But what are the main arguments for going with the code refactoring method in the “rebuild or refactor” debate?
- you avoid the headache and risks that a full codebase rebuild usually comes with
- you get to test every change that you'll make in the context of the already working app
- you deliver all those changes to your app's users progressively rather than all at once, as a whole
- you get to make small changes to the code and check the instant results
- restructuring code is usually more straightforward than rewriting it from scratch; it's usually easier to address the issues that come up
4. When Is It Best to Refactor and to Keep Fixing the Existing Project?
There are specific scenarios when refactoring your legacy code is a more suitable choice than rebuilding your software product from the ground up:
- when you're dealing with “battle-tested” code that's still working; code that's “ugly”, due to years of neglect and just needs a bit of... cleaning up
- when the potential resources and time invested in a rebuild aren't “blotted out” by the estimated benefits
5. Rebuild or Refactor: Factors Favoring One Approach over the Other
It all comes down to your specific context:
There are cases when iterative improvements make more sense and there are scenarios when starting off from scratch is the best solution.
Now, here are some key factors to consider when dealing with a “rebuild or refactor” type of dilemma:
- Is the code in question being run in production?
- How large is the codebase?
- What's your timeline?
- Does at least 80% of your codebase need refactoring? Then you might want to consider rewriting the entire code from scratch
Software rewrite vs refactor: is it any clearer to you now which one of these 2 approaches best suits your scenario?