Cookie notice

We use cookies to provide you with the best experience on our website and to improve our communications with you. If you continue without changing your settings, we’ll assume you’re happy to receive all cookies on this website. If you wish, however, you can change your cookie settings at any time. Click “find out more” for detailed information about how cookies are used on this website.

Find out more OK
Scroll To Top


The Software Dilemma: Rewrite or Renovate


As a homeowner there may come a time where you are faced with the penetrating question: Do I remodel key living spaces, or do I completely tear down and rebuild? This question usually stems from the fact that your initial needs and desires have changed. Perhaps you now have kids, or maybe you’ve started entertaining more. As your needs change, your environment must also change to adapt to your new realities.

An almost identical set of questions and considerations can be applied to an established software product. Since your initial product release, your customer’s pain points have changed. For example, if you are dealing with a legacy product, your customers are likely to be more mobile-focused than they would have been at the time of your initial launch. Or, perhaps they now desire a cloud-based solution to help mitigate upgrade headaches. You may also be the potential to integrate with new systems that have become critical to your customers since your initial product launch. The technological environment is ever changing and as such, it’s critical to consider how to react in order to remain competitive in your market.

Many companies have a natural inclination turn to a full rewrite in order to address these amounting challenges. Product and development teams will often profess the wisdom of such a path stating:

  • “We will have a greater quality of software”
  • “Our software will be much more usable”
  • “Our speed of development will be improved ten-fold”
  • “Performance will be much better”
  • “We will be able to attract developers as they love to build new and use the latest technologies”

Regardless of how inspiring these statements may seem, if you decide to embark on the journey of a full re-write, you should consider the following implications.

“The present code is impossible to work with – we can’t innovate!”

Unfortunately, this statement is not always true. Developers have a natural inclination to work on code they have developed themselves. Very rarely do they want to dig in, analyze, understand and modify existing code. The secret sauce of working with existing code is the inherent stability built into it. That feature and its underlying code has been used many times over, had bugs reported on it, had subsequent fixes implemented – you don’t want all that goodness to go to waste! Innovation will come easier on a stable codebase that you and your development team can count on.

The natural follow-on to this is that if a rewrite is decided, there is no guarantee that your new code will be any better. Your new code will still need to go through its own hardening process through initial release, bug fixes. There is no way to get around this.

“The re-write will be done in no time, trust me!”

This is a very daunting statement. This statement assumes that the world stands still while waiting for your new solution. The reality is that your competition continues to move, as does technology itself. Relinquishing market leadership, even for a short period of time, can be very costly. The promised leapfrog result of a re-write rarely ever materializes as the landing spot of the market nearly always surpasses your efforts.

So, what to do?

In order to avoid a complete re-write, your development team can choose to re-structure or re-factor. These concepts will help tactically focus your team on areas of the system that truly require new functionality.

There is a slew of great content that can help your team figure out where to begin their journey.

A classic article is by Joel Spolsky: Things You Should Never Do, Part I. It outlines the peril of a re-write and uses the case study around the memorable internet browser, Netscape.

Another compilation of content that covers all angles resides on Tech Beacon titled, Rewrites vs. refactoring: 17 essential reads for developers.

The perceived wins of doing a full rebuild of your house may be exciting. Sparkling new designs with premium finishes, why wouldn’t one want to start fresh? However, are you prepared to deal with construction delays, shoddy new work and living with your in-laws while the work is done? These are sobering realities. Please, consider the true and very likely trade-offs in such a venture – a software re-write is no different.


Rahul Nirula
Portfolio CPO
Volaris Group

About the Author

Rahul Nirula's Photo

Rahul Nirula
Portfolio Chief Product Officer