Re: Re: (OT) Rewriting, from scratch, a huge code base

[dragonchild]

in reply to Re: (OT) Rewriting, from scratch, a huge code base
in thread (OT) Rewriting, from scratch, a huge code base

I disagree with this. Very often, the bloat and bug-fix-but-not-really-cause-it's-now-unmaintainable creep ... that makes the application completely unworkable. I've taken applications that I could rework and I've taken applications that were completely unfeasible to rework and that rewriting was a matter of 2-3 weeks, most of that reading the horrid application cause there were no requirements. (And, yes, it was large ... before I got my paws into it.) And, I got rid of unnecessary misfeatures and streamlined the code and migrated it from Tk to CGI and sped it up 5-fold.

So, don't say that rewriting is bad-horrible-evil-unclean. That's like saying "GOTO is bad in every instance". Wrong. It's bad in almost every instance. But, that's why they pay us the big bucks - to figure out that 1-100 instance where goto is not only not bad, but even suggested.

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[ducky]

So you say you don't agree when in your example you say the project was poorly implemented, poorly documented, and unmaintainable? This is exactly why a rewrite is justified. I'm also saying that if it is properly implemented, well documented, and maintainable then the arguments for a rewrite are rather thin - just refine what you've got.

The article Ovid posted was essentially saying, "A rewrite is bad when the code a) works, b) is bug fixed, c) well documented, and d) the over-all design is sound." If the project is missing too many of those points, a rewrite is justified. How many of those points and to what degree are need to justify a rewrite are, like you said, why we get paid the big bucks =)

-Ducky

[dragonchild]

Fair enough! :-)

------
We are the carpenters and bricklayers of the Information Age.

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

[tilly]

Did you read the same article that I did?

The article was not saying that the code should not be rewritten when it was good enough. It was saying that you should not undertake to rewrite from scratch a large body of code that is doing its job. He said that even though you, the programmer, don't see it, if the code runs and has been in use for a while, it is bug fixed. Even if it looks like a buggy mess, it has a lot of important obscure fixes in it. The lack of documentation is given as an argument against replacing it. The soundness of the overall design is irrrelevant to what was said.

Very specifically the claim is that when you rewrite a large application you are throwing away years of work that you will need to redo just to get where you were. Years that you don't have. Years that will kill your user base and business. And you have no reason to believe that you will do it any better.

In short, there are no cases where he thinks a rewrite from scratch is a good idea. He thinks it is always a mistake. And he doesn't say that it is just a mistake, but that it is "the single worst strategic mistake that any software company can make". (Emphasis in original.)

[ducky]

Perhaps I read a little to much into this:

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it. It doesn't acquire bugs just by sitting around on your hard drive.

I interpret this as, "Age of the code is irrelevant. But if the application blows up on unexpected input and after careful review found to have been designed wrong there can be justification for a rewrite."

If I'm totally way off base and this is a "GOTO is never good" article, I completely recant what I posted earlier and deem this article useless for its too hard-nosed approach about programming decisions. TMBOOWTDI - There Must Be Only One Way To Do It? No thanks. I'd rather be allowed to bend the rules when I can justify them adequately.