To rewrite or refactor a legacy system, that is the question. The answer depends on the circumstances.
Gravit-e has had its hand in both approaches. A legacy system that’s outdated or has gone awry can certainly be the bane of a developer’s existence. It’s not uncommon for clients approach us with software that is:
- Outdated and unsupported
- Developed without following standards and with no architectural direction
- Made by rogue developers that have disappeared mid-project
These circumstances have potential to brew projects that can only be described as a developer’s living nightmare; hard to read, full of copy-and-pasted code, and rampant with bugs.
Nevertheless, we do take on these legacies, not to pronounce them dead, but to build upon resuscitating their useful remnants as much as possible. Of course, in other cases there is just nothing worth salvaging, in which case we look to the daunting task of a big bang rewrite — starting all over again. Polarized views exist on the matter. Determining which approach is best largely depends on the mess handed to you.
Fixing the Legacy or Doing the Big Rewrite?
Whenever possible, Gravit-e goes with the former. Doing a big rewrite (a.k.a Greenfield Development) often appears to be the more attractive option — working in fresh, constraint-free environment instead of working on an old and potentially broken system. However, refactoring (changing the code’s internal structure in steps without modifying its external behaviour) the existing code while adding features can often be a better and safer option.
The Paradox of 2 Competing Systems
Rewriting entails maintaining your existing systems whilst rewriting your new system. A paradox occurs in this situation. Onboarded developers given a Greenfield to replace an existing legacy system while existing developers must deal with the current system undergoing constant change.
The blog post “The Big Redesign in The Sky” illustrates this paradox well.
It’s difficult for recently onboarded developers with a “fresh start” to develop a system that perfectly improves upon its predecessor. Especially when that legacy predecessor, that’s functioning as its developmental point of reference, is also continually being updated and maintained. This paradox wastes time, and money (money being the operative word) while potentially resulting in two faulty systems dancing haphazardly with one another. The new rewrite can fail to meet requirements as it may never match the ever changing legacy software.
The paradox leads to another painful outcome from a rewrite: the inability (or refusal) for the customer or client to adopt the new software because they have grown accustomed to the legacy system. After months of work and expense, this is a dreadful situation.
You can live vicariously and read more about this possibility in this blog post here.
So how do you avoid these adverse outcomes and solve this dreaded paradox?
Leveraging the old system by refactoring and building on it instead of starting another project from scratch to remain agile and cost effective. There is no use in reinventing another wheel when you can simply add on a motor and frame to your existing one.
Why You Definitely Shouldn’t Rewrite
Here are five barriers to doing a significant rewrite as outlined by onstartups.com and paraphrased by myself:
- Timeframe: The rewrite will take longer than you think despite your working knowledge of the legacy’s requirements.
- Markets or companies change: in the time that you re-wrote your software, the market or company ecosystems might have shifted. The intended rewrite requirements may no no longer be relevant.
- Existing Customers (Or Employees) can become frustrated: Your current customers or employees might need solutions for bug fixes that you may not be able to provide immediately. Sometimes there are not enough resource to maintain your legacy software while working on a rewrite. If you onboarded developers to do just that, the paradox that emerges from working with two competing systems (as described above) will have you losing more sleep as your customer or employee base grow more frustrated.
- Refactoring can clean up the code: The headaches that you or your developers will have from a paradox-inducing rewrite can far exceed the headaches from working with what you already have.
- Lost Opportunities: You lose the ability to respond to opportunities as a result of a shifting market. New external or internal factors may come and reshape the market, client needs and company processes. You may lack the agility to respond and adapt the new system to the changing environments.
After all that, when does it make sense to rewrite?
- The Code is irreparably broken and outdated: If the existing software is running on a platform that is no longer maintained,supported, nor receiving security updates, a rewrite is probably well worth considering.
- Pivot or other significant business change: Companies evolve over time. That evolution is significant. It’s vital to respond to that change, pivot, and rewrite to stay relevant. For example, Twitter used to be a service called Odeo that curated podcasts! If it hasn’t been properly maintained, it’s possible that much of the complexity — and mess — in the legacy system revolves around old business rules and functionality which are now worse than useless.
- Lessons have been learned; if the existing system hasn’t been around for all that long, and in hindsight many mistakes were made in its development, it may make sense to start from scratch. It’s important to learn from mistakes. In this case, you are essentially treating the old system as a throw-away prototype.
So, What Now?
Salvaging legacy applications through refactoring is often the more cost-effective and safest approach, though it depends on the situation. Generally, you should only consider rewrites when there is no other realistic option, and even then only after sufficient due diligence has been performed.
What challenges do you face with your legacy system? Contact Gravit-e for your next software modernization project!