But sometimes ripping out the plumbing and throwing the bigger pieces back together works wonderfully.
I guess that's called refactoring, though. :)
The point I'm getting at is, who does The Big Rewrite? I can't ever see myself wanting to rewrite sections of code that are working perfectly fine Just Because.
How much of The Big Rewrite was Mozilla? Did they literally rewrite everything? I can't imagine so. I bet they kept a LOT of code. It was probably more along the lines of a rather daunting refactor.
I'm just wondering what "starting fresh" means. For me, it normally means fixing architectural decisions that have become a huge pain in the but I'm keeping a LOT of the code base.
In many environments, specific refactorings are pre-packaged, such that they know their preconditions for working properly, and work with almost mathematical precision. In these sorts of environments, with additional support like Unit Tests, you gradually morph from one structuring of the system into another. This can be a lot safer than "ripping out the plumbing and throwing the bigger pieces back together." (I've also done the rip/reassemble thing. It's often fun and yields good results too.)
Of course, doing that as a one-man team with a closed-source commercial product that you have promised to give away for free doesn't seem like the kind of thing that can get done.
It worked out ok for end users, but didn't lead to such a great outcome for Netscape.
It's a difficult decision to make, the choice between improving an existing code base that has grown warts against the temptation of starting fresh and fixing what went wrong the first time, under the guise of learning from past mistakes.
I guess the lesson is: Don't try to rewrite your codebase from scratch unless you understand that you will spend an order of magnitude more time on the rewrite, even factoring in the experiences you have gained from doing it once.