5 reasons why rewriting an application from scratch is a bad idea

When building an application, you will for sure reach a moment when someone suggests you do a complete rewrite. This could be your developer or anyone else (including yourself). This scenario might be tempting as, in most cases, the software you have is not ideal. It has bugs, breaks from time to time, doesn’t scale well, the existing code is ugly, the framework you use is not maintained anymore, etc. It might feel a bit like wading through a vat of molasses. You feel like this is the best solution to all your problems, maybe you can already see the shiny new application that you are going to build and the money it will earn, happy customers, no bugs, etc.

Think twice before rewriting application!

Truly, believe me. If you don't trust me, keep on reading, I will describe the pitfalls of a complete software rewrite, give you real-life examples, and connect to smart people who will tell you that you should not rewrite your application from scratch.

1. Time needed for a complete rewrite

App development from scratch takes time, usually a lot of time. For a mid-size software solution it could take a year or two, and several years for bigger applications. For almost all companies, this is far too long to wait for a new version of the software. Keep in mind, that your development team will be working on this version, so you will have to postpone most of the changes, new features and improvements in your current version. current version.

2. Specifications of old and new features

Most of the applications that need a complete rewrite have been working for several years. In fact, those apps are made up of years of changes and improvements. Almost no one has up-to-date documentation for such an application, and there is no reliable way to create such documentation. We worked on dozens of "old" applications, and they never had updated documentation, nor did the business people know how all the features should be working.

3. Bugs will not disappear even if you completely rewrite your legacy code

Usually, when the code is delivered for the first time, it contains bugs. Some bugs are hard to find and reproduce, it takes weeks or even months to spot them so that developers can fix them. Such bugs are probably already fixed in your current version. Not all, but certainly a decent number of bugs are already fixed. Such bugs are hard to predict so, in most cases - they will happen again in your shiny new version if you decide to rewrite it. Still, it will take weeks or months to spot them, and it will take time to fix them.

4. How will the market react to your complete software rewrite?

Ok, so we know it will take a lot of time to write the new version, one that might not have the same functions as the old one but will have some of the bugs the old one had. Knowing this, it might already be hard for you to accept such a situation, but just try to imagine what your clients would think. Obviously, they will not be happy. No significant improvements for a couple of years, and when the new version is released it will have fewer features and more bugs than the old one.

On the other side of the market, your opponents won't wait. They will probably make great use of the gift you gave them!

5. Costs of full rewrite

Costs are just a summary of the points above. The time needed to write the new code, figure out the specification, fix bugs and pacify unhappy customers. This all will cost you. And it would maybe be ok if this was an investment, that will turn profitable in future, but in most cases, it isn’t.

Examples

If you search for this topic you will find dozens of examples of companies that failed due to a software rewrite, but here are some of the more interesting/popular ones.

Netscape ...

At its best moment, Netscape Navigator owned 90% of the "Internet browser" market. Unfortunately, for different reasons, mostly connected to technical debt, it lost its place in favour of Internet Explorer. Netscape tried to fight back and introduce the new features that IE offered, but the code was too messy. At that moment Netscape decided to write the browser again from scratch. The effect was the opposite: developers focused on the new version, so the old one did not get enough attention and improvements. The rewrite took too long, so users didn’t want to wait, and they changed to IE. After Netscape finally released the new version of Netscape Navigator, it turned out that the browser had lots of bugs and lacked performance.

... Microsoft Word ...

In 1991, Microsoft decided to rewrite Microsoft Word from Scratch, but they abandoned the idea after a period of time due to the amount of time needed to finish such a rewrite.

... and more.

Both of these examples are pretty old but, unfortunately, the rewriting hasn’t gotten any better during the intervening years. You can find newer stories on Google, here is one example.

So what alternatives do I have?

As Paulina mentioned in her post there are four scenarios that we use to fix the technical debt. Rewriting is one alternative, however, in our opinion, it’s a very tricky and dangerous one.

Want to know more? We plan to write a series of articles on this topic containing useful tips on how to improve your software. Subscribe to our newsletter and be sure to get notified.