"
The road to hell is paved with good intentions." — old proverb
Joel Spolsky wrote something about software rewrites in his blog (
http://www.joelonsoftware.com/articles/fog0000000069.html) and I agree with many of his points, having experienced them first-hand. It was my first project here in the US and it was a five-year, $50 million, 100+ person, total and complete failure. The project name even had "Rewrite" in it and ironically, the acronym was "CPR". It was, of course, DOA. Actually, it was DATS (Dead at the Scene).
I think one of the biggest pitfalls in a full software rewrite is more basic and insidious: hubris. Programmers will often look at poorly-written code and pronounce that they could do much better. They don't take into account that they have the benefit of hindsight. They also have the benefit of knowing more about what the software should do. But when it comes to delivering on the claim, they will more than likely make the same kind of mistakes the previous developers made.
Besides the things that Chris mentioned, there's one thing that often gets overlooked when a rewrite is in play: organizational structure.
Conway's Law states that software reflects the structure of the organization that designed and developed it (paraphrasing). In my experience, this is absolutely true. The key elements to successful software development are
communication and
collaboration. The quality and level of communication and collaboration that occurs is dictated largely by how the organization is structured. The other thing, too, is
culture, which feeds into how well people communicate and collaborate.
Think about it: Most, if not all, problems in software, or anywhere for that matter, can be traced back to some kind of misunderstanding and failure to communicate. Whether those misunderstandings are between people or between people and machines — bugs are a form of misunderstanding — it doesn't make much difference: misunderstandings result in things not working the way they were intended to work.
I think Chris' more holistic view of re-engineering in this book is a good reminder of the other aspects of a project that must be made better if you're going to improve your software development process. However, the book seems to deal mainly with things that are more technical in nature. Section 1.4 of the book does talk about Legacy Culture but I don't know how much more detail and discussion is given to it later on in the book. If there are any holes in the book, this aspect may be one of them.
How do you address these kinds of issues? Well, I have found that while it does not guarantee success,
Agile Software Development, when done properly, can help tremendously. I find that it's not so much the techniques involved when you do Agile development but rather the collective and individual mindsets and the cultural change that comes with it that make Agile so much better than traditional software development. It's not a silver bullet by any stretch of the imagination but it certainly is an effective tool in the right hands.