Great article. I’ve been involved in a number of these types of situations, and I have my $.02.

Pulling this up one level, one of the key factors in this decision is to convince everyone in the company that this is key strategic business decision that needs to be analyzed from many angles. Key business problems that drive this kind of evaluation often include customer satisfaction problems, customer delivery problems (especially in the case of software+service type solutions), the inability to innovate and falling behind competitors, cost of development. Talking to folks in all parts of the business (executives, sales, marketing, support and services) is critical to truly understand the key business problems that may help drive the rewrite or rescue problem. It also help ensure that its not just that the development team wants to rewrite….

I’ve found if you can demonstrate how a certain direction will alleviate these issues, you can get strong decisions made from the top that help drive the decision through the organization.

Another key factor, is that a rewrite decision is a huge risk from a business perspective as it takes a significant investment and based on the “average” success rate of software projects. That risk goes up exponentially if there is not solid buy in and commitment from all key people in the organization.

Finally, for us, in all these cases where the analysis was done, the case for rewrite made in solid business terms, getting buy in from all parties involved, and then doing all the right things in terms of doing the rewrite (good architecture, good team, good process) it was a big success and the best decision for the business.

-Kamal

There is a classic article on this subject (and the thoughts above mostly parrot things I’ve read in the following):

http://www.joelonsoftware.com/articles/fog0000000069.html

You might also want look at our Parabuild for Continuous Integration http://www.viewtier.com/products/parabuild/index.htm

I would add the following based on this experience:

it can be good to identify a core piece of the existing system, break it out as a module or subsystem, and re-implement it first.

Sometimes attempting to re-write an entire system is too overwhelming given the people and time available. Once a core part is rewritten, spec’d out, nicely documented in psuedo-code or whatever, and solid testing is in place, it becomes much easier to expand out and rework the remaining parts.

Being able to test the behavior of the new implementation and compare it with the existing system is really critical. The tests help people become confident in the new implementation and also expose differences between the new and old systems.

The system I worked on was somewhat gnarly and had evolved over time and there was no complete specification. It turned out to be easiest to write a compact description of the desired behavior as a side-effect of the re-implementation effort. This work also exposed a significant bug in the old system, where its actual behavior failed to satisfy one of the key high level behavioral goals.

Another point: sometimes it helps to pretty much ignore the existing implementation (especially at the code level). In this case, re-implementing from the desired behavior without looking at the existing code seemed to go much faster than attempting to rework the original system. This worked in combination with the first point: trying to rework the entire system and trying to understand the whole thing all at once was like walking thru a bog.

By the way, I’d like to put in a plug for test-driven development. Even in a situation like this where you’re re-implementing something, it really helps to first think of examples of the desired behavior, write tests, and then implement to pass the test.