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

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 full 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 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.


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

1. Time

Writing an application 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 your developers will be working on this version, so you will have to postpone most of the changes and improvements in your current version.

2. Specification

Most of the applications that need a 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. 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

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. Market

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 then when the new version is released it has 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

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


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 favor of Internet Explorer. Netscape tried to fight back and introduce the 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 these examples are pretty old but, unfortunately, rewriting hasn’t got 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 take to fix 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.

Michael Kurzeja

Michael Kurzeja

CTO and co-founder of Accesto with 8 years experience in leading technical projects. Certified Symfony 3 developer. Passionate about new technologies, he mentors engineers in developing high-quality software. Co-founder of Wroclaw Symfony Group.

Subscribe to our newsletter

You may also like:

This website uses cookies to guarantee the best experience for the user. If you continue browsing, we consider that you agree to their use.