Chad Fowler on the edge of the years did a great job collecting most of the reasons why “rewrite it” software project fail.
- Original code is unmaintainable. If it would be otherwise, there would be no “big rewrite”
- No software requirements documentation.
- “Use Software as a Spec” also fails .
Invention vs Implementation:
My experience says that most of the time, people doing the Big Rewrite will assume that they’re doing an implementation and will staff and estimate accordingly.
Infinite “must be” and “wanna be” features list:
Imagine going to the hospital for a kidney transplant, and before and during the surgery saying to the surgeon: “Oh, and while you’re already in there digging around, I’ve had some problems with my lungs that could use a little attention. And, yes, I’ve been overeating terribly—-could you do one of those stomach reduction things I hear about? And on that note, how about a little plastic surgery since we’ve got the knives out?”
Big Bang release
But by making it a Big Bang release, you’ve maximized the chances that you’ll be behind schedule when you get to the end, and you’ve therefore maximized the chances that you won’t spend enough time preparing. This results in a bad time for both you and your customers.
Justifications for Big Rewrite are too close to lies. And this happens too frequently.
The piles of justification lead to piles of additional work and/or piles of mismatched expectations and disappointment after release.
Existing product frequently coevolves with the “Big Rewrite” version.
The reasons above make any “big rewrite” project to fail, no matter what.
Leave a Reply
You must be logged in to post a comment.