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

Ok, I read the article and I totally agree with it. Ovid, you should NOT completely rewrite a fully functional, in-production application. So go ahead and re-architect that broken, non-scaling app with the knowledge that you may fully adhere to Joel's statements... once it is a bug-fixed, reliable, documented piece of work. =) Not many, if any, of the arguments for just incremental code improvements he states apply to your inherited app.

The way I'd go about not rewriting something like this is exactly how Joel states: moving code around while not affecting what it does until it can be segmented and replaced. But from what you say, a *lot* of this puppy was implemented incorrectly, undocumented, and the over-all architecture isn't sound.

The few times I've had to rework systems like that, I've tried to rewrite some of the base and try to adapt the existing modules to work within that, then slowly work over each part, breaking them into more logical parts, cleaning up the code or just rewriting as necessary... but these were on the order of around 5k-10k lines total (including whitespace, comments, etc). Nothing HUGE, by any means. =/

My $.02, but I feel like I'm just being a "yes" man. =P

-Ducky

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

Replies are listed 'Best First'.
Re: Re: (OT) Rewriting, from scratch, a huge code base by dragonchild (Archbishop) on Sep 28, 2001 at 22:48 UTC
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.	[reply]
Re: Re: Re: (OT) Rewriting, from scratch, a huge code base by ducky (Scribe) on Sep 29, 2001 at 00:31 UTC
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	[reply]
Re (tilly) 4: (OT) Rewriting, from scratch, a huge code base by tilly (Archbishop) on Sep 29, 2001 at 01:37 UTC
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.)	[reply]
Re: Re (tilly) 4: (OT) Rewriting, from scratch, a huge code base by ducky (Scribe) on Sep 29, 2001 at 02:04 UTC
Re (tilly) 6: (OT) Rewriting, from scratch, a huge code base by tilly (Archbishop) on Sep 29, 2001 at 02:28 UTC
Re4: (OT) Rewriting, from scratch, a huge code base by dragonchild (Archbishop) on Sep 29, 2001 at 00:32 UTC
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.	[reply]


"be consistent"
	PerlMonks