Rewriting from scratch

Contrast that with developers wanting to rewrite because of vague frustrations or poorly-defined technical debt. Without a strict definition of the problem, a rewrite is doomed to repeat the same shortcoming as the original.

I've seen the most success happen on teams which can figure out how to rewrite the app one module at a time, while keeping the existing parts functional. This reduces the risk, and allows you to compare the new effort against old code more directly.

2. Mozilla wouldn't exist today if the Netscape team didn't destroy their company by deciding to rewrite their browser engine, no.

Whether we'd be worse or better off is an open question - a living commercial netscape could have kept the browser wars and associated innovation alive longer. On the opensource side maybe the better-architectured KHTML would have gathered more mindshare and funding and evolved into something like today's WebKit faster without the distraction of gecko.

Also, the standard and IMHO valid riposte to the Mozilla rewrite is to observe that while it may all have turned out alright for the public in the end, Netscape didn't survive it. If you are in a business context, Netscape is still a warning about failure, not an example of success!

Most rewrites are undertaken too lightly and with too much naivete. They are approached as projects with a lot of major unspoken assumptions. Often assumptions that are counter-factual. Assumptions such as: at code complete we will have a system that is as refined and defect free as a well-worn system that has been in real-world use for years. Or, there will be no problem with forcing every user to use the new system because it will be in every way objectively superior to the old system starting on day 1. Or, taking on the work of a rewrite won't cause a serious shortage of manpower needed to maintain the old system (or vice versa, the rewrite won't face a serious shortage due to the needs of maintaining the old system). And so on.

Yet such obvious fallacies remain as latent assumptions behind the majority of rewrites.

There are different ways to do rewrites effectively and none of them are easy.

One way is to build a parallel product using an entirely separate team, and having that product compete against your older product directly in the marketplace. This is obviously an expensive route, which is why a lot of companies shy away from it, but sometimes it's the best way to go about things. It gives a chance for a product to mature before it replaces the original. Microsoft did this with Windows, having two parallel teams work on different kernels (NT and 9x) and it took over half a decade for the "rewrite" to win out. This is even more astounding when you consider that originally Microsoft had intended for Windows 95 to be simply Windows 4.0 based on the NT kernel. A goal they didn't really achieve until Windows XP was released 6 years later.

An alternate way to do a rewrite is through refactoring style techniques. Start building the new system inside the old and slowly deprecate and migrate components piece by piece until the old system is entirely gone. This is a very effective way of doing things and has the advantage of being able to scale relative to the amount of development effort available but certainly has its fair share of limitations and downsides (which I won't enumerate).

As far as the Netscape example, they ended up coding themselves into annihilation, as their constant rewrites and architectural buffoonery led them to create a very unstable and clunky browser that was markedly inferior to IE 4 when it hit the market, and they just were not able to respond with any degree of innovation software wise. Also, my understanding is that the seed code for the mozilla project was a horrendous mess that didn't even represent a functional browser at the time and required extensive effort to get to that point.