Refactor or Rewrite

Conversations such as “Oh, this is such a cluttered design”, “This software has high technical debt”, and “What a complex code, uff” may lead to exchanges such as “Can’t we do something about this?”, “Why can’t we scrap this?”, and “Can refactoring make it better?” Essentially, the discussion boils down to the famous dilemma “Refactor or rewrite”. Let’s take a closer look at the dilemma and a few factors that impact the dilemma.

When it takes more time and effort than genuinely required to fix a bug or introduce a new feature in the software due to high technical debt (including high complexity, tightly coupled design, and so on), the software becomes difficult to maintain. In extreme conditions, making each change in the software becomes a painful nightmare. In such situations, the dilemma “refactor or rewrite” may capture the attention of project stakeholders.

History has taught us that “rewrite” from scratch could be strategically dangerous for the product and the company. Joel [1] has pointed out many such mistakes; some of them are:

• Netscape released version 6 during the year 2000 after three years they released version 4 and yes, there were no version 5. Why? Because the company decided to develop the software from scratch! It took three years for them to do it by that time they lost the market.
• Borland bought Arago to make dBase for Windows but started the development from the scratch; before they can make to the market, MS Access captured the market.

All of the above cases highlight strategic mistakes of these companies that wiped their market share. Thus the “Risk of losing the market” is indeed a significant factor to consider when the question (i.e. “Refactor or rewrite”) is posed. In this context, Refactoring could be favored since the product is always market-ready and refactoring can consistently improve the quality to sustain the product for a longer period.

If you think that the old software is a piece of crap that doesn’t deliver any value then think again. The old huge legacy software was maintained by your company for so long and in this duration, the project team has fixed numerous bugs aroused in different client conditions. In summary, the same piece of crap has accumulated huge knowledge and experience which is difficult (if not impossible) to introduce at once in a software developed from scratch. Again, from this dimension, Refactoring option is a fruitful alternative to retaining and exploiting the knowledge captured by the old software.

Does it mean we should always opt for refactoring over rewrite? Well..No. There is at least one case when it is desirable to go for a rewrite. When it becomes difficult to maintain old software technologically (difficult to get compatible hardware, software, or people who can run the show) since the used technology is obsolete while management of the product foresees a relatively long life for the product then rewrite could be an option. However, while opting rewrite, the risk associated with first two factors must be addressed; for instance, the management could decide to develop the new product from scratch with new technology without removing the old product from the market. Microsoft did the same once when they started developing Word from scratch under the project code name Pyramid. Although, the project Pyramid was a disaster but the parallel development saved Microsoft from losing the market.

[1]: Joel Spolsky, “Things you should never do, Part I"