When you’re dealing with legacy code, whether it’s just old or old and difficult to work with, there’s the temptation to simply get rid of it and rewrite it. With superstar developers on board, who are up to date in the latest technologies, and with clean coding skills, it sounds like simply rewriting the application will deliver a better end product.

Indeed, there are many drivers for legacy modernization and for which a complete code rewrite is one approach and sounds like a good idea:

• The language is so old that no one develops in it anymore, or can even understand it
• Your customers are calling for new features the old language/product simply can’t support
• Your software needs to be able to handle new architecture and categorically cannot
• You see space in the market for a modernized version of your product, that isn’t currently possible
• The code is an absolute nightmare, full of hacks and workarounds (and increasing technical debt)

Cartoon: A good reason to rewrite from scratch? (via XKCD)

For the most part, though, rewriting from scratch can be a really bad idea – like throwing the baby out with the bathwater. Want to know why? Here are a couple of companies who could tell you…

Software rewrite fails

One of the most famous historical cases of things going horribly wrong for a rewrite is Netscape. Remember that browser, the first browser? Well they committed a software crime, at what was a critical point in time for the company:

“They did it by making the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch.”Joel Spolsky, CEO and Co-founder of Stack Overflow

Source: Things You Should Never Do, Part I

Netscape 3.0, the biggest browser back then, was released in 1997, around the same time as Internet Explorer 3 – which suddenly was hot competition. And then they decided on a complete rewrite. It took 3 years to make, during which time we got IE4 and IE5, and suddenly Netscape was out of the game. It was all pretty much over, and much of it was due to the extended rewrite process.

So what can we learn from this? Well, for a start, rewrites take a loooong time. And for another thing, don’t ever underestimate the power of your competition to eclipse you during that time. Here are some other, easily researched, examples of failed rewrite projects:

• In 2012, Less Annoying CRM abandoned their complete code rewrite as failure was written on the wall.
• MailOnline failed to rewrite their website with Java EE.
• Even industry heavyweights Microsoft attempted to build another OS from scratch, with their Midori project – development efforts from 2003 were eventually ended in 2015, and the idea retired. With up to 100 of Microsoft’s developers working on the project how much would have been spent over those 12 years?
• A complete rewrite of CouchSurfing’s platform left users with less functionality than the original version of the software.
• IBM’s rewrite of 22yr old payroll software for Queensland Health that cost $6 million to write failed spectacularly when it was rolled out in 2010, messing up payments for employees. The government eventually took IBM to court and lost their case; the cost to the government for the project failure was estimated at $1.2billion.

So why is rewriting so difficult and risky?

Here are some reasons that a complete rewrite is generally an extremely high risk decision with failure the likely outcome:

• The requirements of the software have been lost in the annals of time
• Current system users are used to and generally happy with the experience they already have
• There is no seen benefit to other stakeholders (i.e. it already “works”)
• The code suffers from high coupling, which means you can’t break out sections to rewrite piece by piece
• The developers who worked on the original project have left long before, so the complete knowledge of the system has been lost
• The effort required for a rewrite will likely be far greater than you expect

In a Geneca survey from 2011, it showed that 75% of businesses and their IT departments believe their IT projects are always or generally “doomed from the start”. If you already have working software why would you risk a rewrite when the odds of the project going as expected are so risky?

There are far fewer stories about successful rewrites…

If you dig, dig, dig you’ll find some successes beneath the pile of “oh god we shouldn’t have done that” mistakes.

Basecamp, a successful and well regarded project management tool has gone through several successful rewrites. For a thorough talk by David Heinemeier Hansson, co-founder of Basecamp (also creator of Ruby on Rails) go here. For Basecamp, it was a matter of get eaten alive by your competition or rewrite, with new added requirements – and they chose to do the latter, while still keeping old customers happy by supporting the old version. It worked.

Google even managed to pull it off, with a remake of the acquired Writely, into what we now know as Google Docs. But known successful wins with code rewrites are few and far between.

Since Joel Spolsky’s article was written in 2000, object oriented languages and component based software design, along with agile principles of software development, have become popular.  This is why it can be a lot easier to rewrite younger software products, if they have been designed fairly strictly with these principles. We can modernize more easily if we are able to rewrite components piece by piece and migrate one part at a time. For forward thinking tech houses they might expect that they’ll need to rewrite their software to take advantage of new tools and technologies that will crop up in a few years, and so they consider a rewrite from the beginning of their software project. This is what can be described as sacrificial architecture, a term coined by Martin Fowler in this post from 2014. This can be very, very hard with a legacy software application where these principles and ideas surrounding the software have never been followed.

What’s the solution?

Instead of a complete rewrite, most software is given a refactoring, and functionality is migrated incrementally to a new architecture. But – this isn’t always possible, especially if code is closely coupled, or you don’t have enough experienced developers on hand to refactor the code. For old, large codebases this is generally the case.

To modernize, when refactoring and/or incremental migration is not possible, and without the risk and overhead of a rewrite from scratch, you can instead choose a solution like Morphis. By carefully analyzing systems and architecture, applying an automated solution (with 90%+ automated code coverage), and manually coding the rest, we can achieve modernization of legacy codebases in a short amount of time and can even add functionality to the product as part of the automated transformation. For more on our process read our post When and Why Technology-Enabled Transformation Beats Rewriting – and consider our services instead of a rewrite.

Contact us to learn more.