This is the first in a series of articles, discussing why many software rewrite projects end badly and what to do to avoid some of the ways I've seen them go astray.You’ve got an existing, successful software product. You’ve hit the ceiling on extensibility and maintainability. Your project platform is inflexible, and your application is a software house of cards that can’t support another new feature.
You’ve seen the videos, the weblog posts and the hype, and you’ve decided you’re going to re-implement your product in Rails (or Java, or .NET, or Erlang, etc.).
Beware. This is a longer, harder, more failure-prone path than you expect.
Throughout my career in software development, I’ve been involved in Big Rewrite after Big Rewrite. I suspect it’s because I have an interest in learning eclectic computer languages, operating systems, and development environments. Not being just-a-Java-guy or just-a-Windows-guy has led to me becoming a serial rewriter. I’ve been on projects to replace C, COBOL, PHP, Visual Basic, Perl, PLSQL, VBX (don’t ask!) and all manner of architectural atrocities with the latest and greatest technology of the day.
In many cases, these Big Rewrite projects have resulted in unhappy customers, political battles, missed deadlines, and sometimes complete failure to deliver. In all cases, the projects were considerably harder than the projects’ initiators ever thought they would be.
This is not a technology problem. It’s not at all Rails-specific, but being in the limelight these days, Rails implementations are both very likely to happen and very risky right now.
So, why, in software rewrites, when you’re traversing exclusively familiar territory are the results so often unpredictable and negative?
For the next week, I’ll post specific reasons I’ve seen things go wrong. The following is a list which will eventually be made into links:
Stay tuned.
Sorry, comments are closed for this article.
January 1st, 2007 at 09:11 PM
Good insight. I have recently worked on projects at two different companies where the goal is to rewrite a large production application. Each project is expected to take 10+ developers several years to complete. Each relies on the existing application for requirements analysis. Your observations seem to fit both of them pretty well.
I have also noticed that neither project wanted the new application to work exactly like the old one. Requirements don’t stop changing the day you begin your rewrite, and both projects have to decide which changes can wait until after the rewrite, which ones have to go into the first version, and which ones need to go into the old application as well.
I’m looking forward to the next three articles in the series.
January 4th, 2007 at 08:01 PM
One flawed notion that people often have is that moving to a different language platform will make things better. This is rarely actually where your big savings come from. Before choosing to rewrite you should believe that the flaws are fundamental enough that you could rewrite it in the same language as the original and see a big savings. If you can’t make that claim then you are living in a fantasy land thinking that a change of language will make all the differnce.
January 5th, 2007 at 08:01 AM
“The single worst strategic mistake that any software company can make: [deciding] to rewrite the code from scratch.”
From: http://www.joelonsoftware.com/articles/fog0000000069.html
January 5th, 2007 at 02:10 PM
Are you going to address the justification conundrum? By justification, I mean the management justification for starting a rewrite in the first place.
Managers seems more willing to spend “next years dollars” on maintenance; presumably this is possible because that money is invisible or “already spent” or something. Too many managers seem unwilling to spend some money this year to prevent the ongoing (perpetual, infinitely large) costs of maintenance.
Everyone has a long, sad “capital investment” vs. “expense” story that I just can seem to comprehend. It’s all money, it’s all shareholder value. Why is expense
- perpetual expense -superior to an investment in a rewrite?While there are problems with doing a rewrite badly, in some cases, there are problems even starting an intelligent discussion of the need for a rewrite.
Presumably, you’re analysis begins from the rewrite being commissioned. Can you back up a bit and discuss how to even justify and plan a rewrite?
January 5th, 2007 at 09:38 PM
I’ve been involved one succesful rewrite… The serveside were ported from Gcos 8 (Bull mainframe, Cobol) to java and EJB and in the process numerous bugs in the delphi client were fixed as well.
Several factors that made this a success: - the system had to change so that recent changes in organisation could be reflected in the system ( in other words the users wanted and welcomed change, likewise systemowners wanted change) - every one involed wanted the rewrite to be successful, including users, systemowners (the guys with the money) and the project team - a skilled and gelled developer team eager for success with the help of very competent users and project management team who also wanted success.
All in all not very different from every other successful project…
January 9th, 2007 at 05:43 PM
Rewriting applications on which the enterprise relies is always high risk. One option is not to re-code the whole application but give an old system a new “brain” by renovating just part of it. Business rules can be very effective for this and outperform taditional code while building for change and improving application maintenance. After all, as a couple of Gartner analysts said, “you can’t code your way into the future”.
January 11th, 2007 at 08:59 PM
The big rewrite is something I have been contending with lately at a client, and when I started reading this series of postings, I was just loving it…misery loves company, it would seem.