Tuesday, August 21, 2012

Version 2 "The Rewrite" - don't do it! - never ever rewrite you system

“The second is the most dangerous system a man ever designs” Fred Brooks, 1975 & 1995

Brooks was talking about software designers, architects, but I think the statement holds true not only for all software developers but for the business people who commission replacement systems.

From time to time I come across a team who want to rewrite their system. Usually this is the technology team who are saying “The code is too complex, the thing was written by a jerk, She cannae take it Captain”.

Sometimes is the business side realising that their system looks out of date - Visual Basic 6 controls on Windows Vista, or turn of the century web style.

Either way there is a “Stop the world I want to rewrite” mentality. Sometimes the powers that be buy the argument, sometimes they bless a rewrite or, as one team called it a “Technical Improvement Programme” - TIP for short.

Lets me come to the point: this is always and everywhere a mistake. You should never, ever, rewrite a system just because the technology is old.

This is a mistake because customers don’t want to change. The may think that VB6 controls look odd but they know how to use it. Even if change would benefit them they are scared of it. Plus, they have their own business to run - or life to live - and changing systems is only going to get in the way.

Second, this is an utter waste. Statistics regularly show that as much as 80% of features in a typical software system are not used. So why implement five times more functionality than you need?

One company I worked with commission an cheap Indian company to rewrite an old PowerBuilder application in Java. They were told to make it identical. So they did, they spent a lot of time making Java look like PowerBuilder. They copy every feature, even the ones not used. It was buggy as hell and the users didn’t want it.

Third: the “just a rewrite” mentality leads people to under estimate the complexity involved and to overlook the opportunities for improvement. Why produce a second system which is identical to the first?

Finally, and worst of all: the world doesn’t stop, you can’t afford to stop and rewrite, nor can you afford to waste the opportunity to produce a really good system, one that is better than competitors.

Yes, I agree your current system might be at the end of its life and you might need to throw it away but the solution is not a rewrite. When this happens you have two options.

The first won’t satisfy every problem but is the least risk: refactor your way out of the problem.

Actively encourage programmers to refactor code, of course you need to embraced Test Driven Development at both the development and testing level first of all and start putting tests in. Thats not to say you cover it in tests first and then refactor, rather you start putting the tests in as you go. This is a bit of high-wire act without a safety net at first so I strongly recommend you get some help if you’ve not done it before.

This is real engineering, this is changing the engine oil while the engine is running.

That is the easy answer but it won’t work every time. Sometimes the changes are too much, say from VB6 to C#.

The second answer to develop a new product, a competitor product. One for which your current system/product is the competition. This development effort needs to be market lead and focus on what customers/users want the the current system doesn’t provide.

I’ll say it again: Market led. The marketing department, the product managers and/or business analysts should decide what goes in. Not the developers.

When companies rewrite they jump to the assumption: “The developers know what the current system does so they just need to copy it.” That is the biggest mistake.

Next, get into the market fast, release early release often. Test what you are building in the market, show your company real, usable progress. Remember, your competitor is the current system, if you can’t do better than it you want to know fast.

The objective is to build a system that your current customers want to use, one for which they are prepared to give up the system they have at the moment. Consider this a variation on Same Customer, Different Product pattern (available online or in the Business Patterns book).

Emphasis the things the new system does that the old one doesn’t. Don’t worry about all the features the old one has that you think you need to launch. You might need them in the end but nobody is going to buy your software because it does the same thing. Add them as you need them, you’ll find you need to bring across far fewer than you initially think.

Now I apologise to all the developers out there who are begging their managers to let them rewrite the system. Your code base may be terrible, the technology may be out of date but a development led rewrite is not the answer. Few companies can survive such a thing.


  1. First of all: great article. I agree with most of it :-)

    Secondly: didn't this appear before, briefly, last week? I presume you pulled it so you could rewrite it? ;-)

    Thirdly: You start out by saying, "this is always and everywhere a mistake" - but towards the end you qualify it with, "a development led rewrite".

    I mostly agree with the latter sentiment (there are, still, some rare cases where I think it is appropriate) - but I don't think you made that clear up-front.

    What you call, "a (market led) competitor product" is what I usually think of as a rewrite. i.e. you rewrite it to be what the "market" conditions and requirements are now, rather than what someone thought they were (if that) ten years ago. Whether that is the original motivation or not it should always be part of the approach.
    I think all your other points stand, though.

    1. Phil,
      First: thanks!
      Second: Yes, a draft escaped
      Third: Yes, I did kind of fudge it, but, if you write something with the aim of competing with an existing product is it a rewrite? Or is it something new? Bit of a philosophical question. Even more complex if you steal code from the original (which I encourage you to do).

      The main point is: Don't write code unless you know the market want it or you are using it to test the marker (Lean Startup style)

  2. Do you think of changing to a different platform as a rewrite? For example, taking an old desktop application and rewriting it as a web application? I would say that's a valid case for a rewrite (if that terminology applies).

    1. David,
      Yes I do.
      Porting an App from one OS to another, e.g. from Windows to MacOSX is not a rewrite
      But the kind of move you describe, Windows to Web is. This effort should be market lead

      a) Because your customers will use and relate to the product differently so you shouldn't just copy. Its a wasted opportunity.
      b) Because your competitors will be adding features so why would you stop to create the same thing?
      c) Because until your customers move away from Windows you have to maintain two code bases with two sets of costs. The sooner you will save your money.


Note: only a member of this blog may post a comment.