(This article is part of the Big Rewrite series.)
To add to the stress of the Big Bang comes another, mostly people-related issue. Almost all technology rewrites are driven by some technologist. Behind almost every technologist pushing for a Big Rewrite is a business person saying “But, why?” The question is valid. The product already works. It’s successful enough to even consider re-plumbing it, so we must have already gotten something right, no?
So, then come the justifications. They start with the real reasons the software is being rewritten (but usually censored to avoid the technologist looking like he or she screwed up big time on the initial development of the product). The system will be more maintainable. It will be easier to add features. “Oh yea? So we can do more features faster?” “Uh, yea.” “How much faster?” And so on.
As those discussions get heated and prove unsatisfactory, the list of promises gets longer. The system will be more scalable. System response time will improve for our customers. We will have greater uptime. And so on.
It’s rare, in fact, that a technology rewrite can deliver on all these fronts. A J2EE Web application may not prove in practice to provide higher availability than a mainframe application. Rails might be a more flexible and productive environment for a developer, but Rails apps slightly underperform equivalent PHP apps. So, you don’t sell Rails as something that will be faster than PHP. You sell it as something that is more flexible and maintainable, and will perform reasonably compared to a PHP application.
The piles of justification lead to piles of additional work and/or piles of mismatched expectations and disappointment after release.
Sorry, comments are closed for this article.
January 4th, 2007 at 08:14 PM
There are often very real reasons for doing a rewrite, but the ones you’ve mentioned above are far too absract. If that was the best reasoning the technologist could offer I’d be sceptical too. Things like: The key assumption of all the original development was that “x” and “y” would always be true. Now they aren’t and it’s killing us every day. Or (frankly) we just pushed everything as fast as we could go to do that initial version and we made a ton of mistakes like (name a few) in addition all the business logic has gotten spread out and become unmanagable… etc. If you can’t identify the problem then forget about talking about solutions.
Also if the rewrite doesn’t have a business sponsor who believes in it (not just a technologist) it’s screwed period. Don’t even think about it.
January 4th, 2007 at 08:43 PM
Good points, Kevin. I didn’t really intend to list good reasons to do a rewrite here. I just referred to them (without defining them) here: “They start with the real reasons the software is being rewritten (but usually censored to avoid the technologist looking like he or she screwed up big time on the initial development of the product).”
I agree with what you say here.
January 24th, 2007 at 08:22 PM
(I wanted to add this comment under the main article http://chadfowler.com/2006/12/27/the-big-rewrite but its comments are already closed).
I like to make this kind of points myself, but what I like more is counterfactual analysis. List your options, compare them, choose the best one. Although I agree with most of the points made above, they’re irrelevant until I start comparing real-life alternatives.
Example: Let’s assume that you have a cancer. You got 2 months of life left. You start preparing for your last trip, but then you phone rings and they tell you that there’s this new experimental treatment that can save your life. It’s quite risky and may not be the most pleasant thing you can think of, but it gives you a chance to survive.
The question is: Do you decide to take the treatment or do you sit back and start bit**ing about how risky and insecure this treatment might be?
Of course, redoing the same job once again is never a good prospect for the future, so you do it only when you have to, consciously taking all the risk onboard.
If you got a highly unmaintainable application, a codebase that makes the easiest feature implementation challenging, a database full of potential inconsistencies, then your days are counted. You have to do SOMETHING about it. You can’t cover your eyes and pretend it’s not there.
If your got object oriented modular application, you’re in a relatively good situation – you can rewrite it sequentially with a series of refactorings. But if you got a structural code with all the problems mentioned above, then it’s no-brainer. You have to rewrite it, no matter how risky it is, or else it’s gonna kill you and your company (if the company relies on this certain product).
I’m currently facing a Big Rewrite, and although I understand how hard this project’s gonna be, I’m in, because there’s no alternative I can see.