Convincing management to rewrite a product

Question

A hypothetical organization (we'll call them Sprockets Incorporated) spent millions of dollars to rewrite a product. The rewrite ended with lost time, more bugs, and a harder to maintain version of the product. Does anyone here have anecdotal precedence for convincing upper management to support a rerewrite? Or even a rewrite? How can such an argument be successfully made?

Answer 1

This is of course very subjective, but basically you need to convince them that:

We will spend weeks on this, and if we are successful, it should do exactly what it does now!

Which is hard to sell to management, at least when they don't have a software engineering background.

Answer 2

Look at Microsoft products and do the same.

Answer 3

A low cost solution to improve performance would be to rollback to the old product.

Answer 4

The developer's role isn't to convince - or even persuade - management what course of action to take. Our role is to provide information, as accurate as possible, as to what schedule, cost, and risk are like for various courses of action. Management should have the broader picture - the one that includes benefits to users - and should therefore be making those decisions, based on costs (about which we supply information) and benefits, both.

Answer 5

Arguments in favour:

1. Avoid falling behind the curve: the technology of the old system is becoming unmaintainable/outdated, such as mainframes for cobol systems. Old systems still work (which is why they are "old" and still working [1]), but it's harder and harder to find people with the skills needed, and possibly hardware.

2. Get ahead of the curve: If you know that Competitor X is planning some features which put their very closely competing product ahead of yours, you will probably need to add the same features just to keep up pace. If you want to get ahead of Competitor X, you may need to add new features that they don't have yet. Both of these could require a re-write (depending on new features/functionality) and both situations might be necessary from a business point of view.

3. Long term maintenance: You'd have to show (maybe through a proof-of-concept) that a re-write now will make for a more maintanable (hopefully you can show that this also cheaper) and forward compatible system.

[1] but of course there are probably exceptions....

Answer 6

I think there are many risks involved in rewriting an entire application. Imagine if the new application is worse than the first one. How can you guarantee that this new application will be better?

A better approach is to refactor to isolate the modules of the original application (if isn't modularized yet). Then rewrite or refactor the modules that causes more trouble. This way you don't throw everything away and can improve the application with little steps.

Answer 7

Maybe the first step would be to make some observations regarding to this failure, in order to be aware of what went wrong and take measures in order that it could not happen again ?