Mozilla tossed the Netscape 4.x codeb ase and started nearly fresh with Gecko and then re-wrote components one at a time around that new foundation. It took a few years, but the results were Mozilla 1.0 and Firefox 1.0. 10 years later Mozilla re-wrote much of Gecko and Firefox around a new multi-process architecture and new rendering and style pipelines for Quantum. Gecko is now about 25 years old and still used by hundreds of millions of people and is one of only three web engines today capable of rendering enough of the web well enough to be viable. We have Blink, Gecko, and Webkit and that's it. Blink and Webkit share a very large amount of legacy code, so Gecko is really the only decent alternative, at least from a more academic standpoint. (Want to study two independent implementations of the web platform, blink and webkit isn't really ideal, but either of those and Gecko would be.)

I don't know if there is a good write-up on it but the APR Apache Portable Runtime Library 1.6 to 1.7 rewrite / refactor that allowed the performance of Apache to be on par with NGinx at the time I would call a successful major software rewrite or refactor. (Apache 2.2.x to Apache 2.4.x) The changes in performance were a night-and-day difference especially in combination with mpm-event.

>> I am sure there are good reasons to rewrite software

Absolutely. There are many excellent reasons to rewrite software.

Having a -reason- to do it is not the issue. The issue is whether you can -afford- to do it.

It will cost money (lots of money), it'll cost time (make your best guess, multiply by 5), and it'll cost you your best developers (since you'll need a new team, and the old ones will see the writing on the wall) and by extension it'll cost you the experience your current team have earned over the years.

If you can afford all this, then you at least have a decision to make. If you can't -afford- it then the reasons for doing it are meaningless.

[I'm obviously talking about significant systems here, not a Notepad clone.]

I've seen rewrites of systems in FAANGs that would tank revenue to zero if the system went down. Usually it occurs over 5+ years with 30-50 people, even then every last detail is usually never hammered out.

Does that mean that 5+ years go by before code starts running in production? How do you cope with the existing system evolving as the rewrite is taking place?

I feel like the historical context here is important.

Today it’s more common to refactor some component into a service out of a monolith. Then maybe some later time rewrite that. And so on.

Whereas when this was written a “rewrite” would be the equivalent of rewriting the entire monolith.

Nowadays when people say “rewrite” they mean something closer to what this post called a refactor. Still risky but not the same as completely throwing away what’s in prod and investing N years on some promised future that doesn’t manifest.

One notable example is the rewrite of Netflix's video streaming platform, which improved performance and scalability. Another example is the rewrite of Slack's desktop app, resulting in a more efficient and user-friendly experience. Software rewrites can be challenging but can lead to significant improvements!

https://linuxfr.org has been successfully rewritten from PHP with a exotic framework (templeet) to Ruby on Rails.

You may laugh, but I hear, Evernote server side was once rewritten from C# to C++ to make it work faster.