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.)

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.

I think you did read too much into that. There is no "but" in what he said. And his title, Things You Should Never Do, Part I, indicates that the omission is not accidental.

------
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.