If you’re considering doing a system rewrite there are a couple of posts that I would strongly recommend you read. The first is by Joel Spolsky about the folly of doing system rewrites called “Things you should never do“. Go read that first. I’ll wait…
The second is a great response by Dan Milstein that gives some really useful advice and tips on how you might approach doing this, if you really have to, with the subtitle “Screw you Joel Spolsky: We’re rewriting it from scratch”. The slightly more positive title of Dan’s post is: “How To Survive a Ground-Up Rewrite Without Losing Your Sanity”.
While there are loads of great points that he makes, Dan does a great job highlighting one of the critical reasons we need to focus on delivering value early and often:
Be very, very careful if the primary business value [for doing the rewrite] is some (possibly disguised) version of “The new system will be much easier for developers to work on.” I’m not saying that’s not a nice bit of value, but if that’s your only or main value… you’re going to be trying to explain to your CEO in six months why nothing seems to have gotten done in development in the last half year.
This is one of the greatest stakeholder risks, that is rarely taken into account by the people managing delivery. When nothing is coming out of development, the pressure from stakeholders goes up. The typical response to this is to add more resource and attempt to scale, and we should all know by now what effect that has: it makes things slower.