When is a re-write acceptable?

Question

I know this is a generalized question, but some input will definitely help.

We have numerous small applications (web and win), all running smoothly (maybe a bug or two), and all making solid income, but we find that every year or so, the developers start to itch, and want to do a rewrite.

Generally i will agree, cause i come from a development background, and i know that working on old code just make me screech. However, when does one draw the line?

Implementing newer technologies when you rewrite the app allows for greater future integration, but... when integration time comes, it's time for a re-write :)

So my question is: When will you consider a rewrite?

Answer 1

"If it ain't broke, don't fix it"

We recently rewrote (reimplemented) a large portion of our JavaScript layer for our web app, was it broken? Kinda, we couldn't extend it as much as we wanted, so a rewrite was feasible.

Developers will of course want to play with the latest and greatest technologies etc, that along doesn't mean you should let them rewrite your entire system.

Answer 2

Developers itching is not a good reason to do a rewrite. If the code is solid and the requirements don't change much a rewrite is just a bad idea.

A rewrite is a very big undertaking, and should only be considered if the architecture of the current app can't support the new business need. In other words you should only consider a rewrite if the application you are trying to build is not what you originally built. It is natural for applications to change over time and take on new capabilities, eventually what the application is currently trying to do will become increasingly difficult if it has diverged from what was originally written.

For example you can take an application which was written to work on a console and give it a GUI, eventually the fact that it was written for a console may make implementing the GUI difficult and may no longer be a requirement. So considering a rewrite at such a point may be appropriate.

This assumes that the current application is not a completely bug ridden monstrosity which will never be able to fulfill the role that you intend it too.

Answer 3

Duplicate of this, I think.

Answer 4

You do a rewrite when the benefits exceed the costs.

Depending on how formal your environment and the expertise available in project and management accounting, this could be anything from a feeling in the gut of an experienced project manager, a full-blown cost-benefit study (with discounted cash flows, net present values, risk analyses and all that good stuff) or anything in between.

Beyond the straightforward costs of staff time, software licences and hardware purchases you might want to consider costs such as:

• the increasing difficulty of finding new staff with an ageing skillset;
• the decrease in maintainability of existing applications as the people who wrote them move on;
• the possibility that the rewrite will upset software users to the extent that they switch to another product;
• lots more ...

and benefits such as

• increased attractiveness of your shop as a place to work as you keep up with new developments;
• opportunities to enhance products (and the income they earn) when you rewrite them;
• lots more ...

Itchy developers are not a good reason to rewrite anything. If your developers are itching, get them to scratch each other -- if you've ever seen chimpanzees grooming each other you'll have some idea of the benefits.