Legacy Software: To Rewrite or Not To Rewrite?


To rewrite or refactor legacy software, that is the question. The answer is really dependent on the circumstances, and Gravit-e has had its hand in both approaches. Legacy Software that is outdated or that has gone awry can certainly be the bane of a developer’s existence. It’s not uncommon for clients come to 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. Though views are well polarized on the matter, determining which approach is best large 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 . But 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 often occurs between onboarded developers given a Greenfield to replace an existing legacy system, and existing developers still having to deal with the current system also undergoing constant change. Blog post “The Big Redesign in The Sky” illustrates this paradox well. Recently onboarded developers with a “fresh start” are often unable to develop a system that perfectly improves upon its predecessor, as its legacy predecessor– that functions as its developmental point of reference– is also constantly being updated and maintained.

The potential result? Two faulty systems dancing haphazardly with one another and time and money (money, the operative word) wasted. The new rewrite can fail to meet requirements as it may never match the ever changing legacy software. Another painful result is the rewrite not being adopted at all by the customer/client as they had already gotten used to the legacy that is also being maintained, a dreadful situation after months of work and expense, as seen in the blog post here.

The solution to 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.


Reasons Not to Rewrite

Here are some barriers to doing a big rewrite as outlined by onstartups.com and paraphrased by myself:

  1. It will take longer than you think; the rewrite will take longer than you think despite your working knowledge of the legacy’s requirements.
  2. 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 not be relevant.
  3. 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’s 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.
  4. Refactoring can cleanup 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.
  5. Lost Opportunities; new external or internal factors may come and reshape the market, client needs and company processes, and 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, not receiving security updates, and which is not being supported a rewrite is probably well worth considering.
  • Pivot or other significant business change; companies evolve over time, and sometimes that evolution is significant. 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. 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, rewrites should only be considered when there is no other realistic option, and even then only after sufficient due diligence has been performed.


Do contact Gravit-e for your next software modernization project!