When to fix and when to rewrite

We have all faced the dilemma of whether to fix or rewrite software. Unfortunately it’s never a straight forward decision. Many industry heavyweights say NEVER rewrite, whilst others say it is only OK in specific circumstances.

The reasons for wanting a rewrite are usually based on the following:

The existing code is crap: the code displays all the features of a big ball of mud, and exhibits the usual code smells that indicate the code should be quietly taken outside, lined up against a wall and shot – the code that is, not necessarily the developers, but sometimes…

We now understand what it’s supposed to do: Agile development techniques build of the principles of only delivering what is immediately needed or know. This is then added to and extended continuously as new requirements, features and understandings emerge.  Without rigorous attention to refactoring, the code base quickly descends into a quagmire of modified methods, classes and objects that are now doing things they were never initially intended to do.

We want to use this new funky programming language: With the plethora or new languages, tools and techniques. MVC, JavaScript libraries, document databases, new devices, mobiles, tablets…

We need a bunch of new functionality: we want to add these great new features.

In most cases, don’t do itdo not rewrite from scratch. It is well documented that rewriting and existing application from scratch is almost always a bad thing:

  • It almost always takes much more effort than you expect.
  • What is to say that your New code is that much better than the old. It is well know that developers always want to work on the new, latest, shiniest piece of code. Working on old code is always Hard, especially if you didn’t write it in the first place.
  • It is usually far more complex than you anticipate. The original developers resolved a series of problems to come up with their final solution. You will probably need to resolve those problems again – so why reinvent what has already been done?

When is a rewrite acceptable?

However, there are some cases where a rewrite is the only alternative:

When the cost of inaction far outweighs the cost of action

This means that if you can measure the cost or risk of not rewriting your application, and compare that with the costs and risks of a rewrite then it’s a no-brainer. I have worked on applications that are so completely screwed that even an infinite number of monkeys with typewriters would give up and go to StarBucks. that’s when you know a rewrite is inevitable.

When a major platform change is required

If you find that you need to move say from console/character based to windows/web based, and the existing UI is heavily embedded in the existing code a rewrite may be more cost effective.

When a very significant change or addition of functionality is needed

You need to make the application do something it was never ever designed to do. “That functionality we said We will never ever need… Well things have changed!”

Try not to start from scratch

Given the indicators above, even if a rewrite appears to be the only viable option, if the technology allows you should always try to migrate, refactor, adapt or re-engineer your existing application. You will be starting from a (hopefully) working application and re-using whatever existing code or functionality that is salvageable. There are a number of techniques for doing this from standard refactoring to my favourite the Strangler method .

When all else fails

On those occasions when there really is no choice but to start again, do it properly. Go back to your business owners, customers or designers and start from scratch in understanding exactly what he new application is required to do. Do not copy the old application. Do not look at the source code of the old application. Do not look at the database design of the old application. Start from scratch with a clean and clear set of prioritized must have features and functions.

Of course, review the old application from a functional perspective. What features work, what don’t work, what could be improved.  However, beware of reproducing faithfully all the functionality especially that which is either superfluous or more worrying put into place to work around other issues or other systems.