Classic Mac OS was written at a time when computers had kilobytes of memory and black and white graphics. It was not designed for multi-tasking, because at the time it was written, the world had insufficient hardware to make multi-tasking practical. It was not designed for networking, because the internet mostly did not exist at the time. It was not designed for security, because computers were a less important target for criminals, and no internet meant far fewer exploit vectors.

All of these features were post-facto bolted onto Mac OS, and the result was an unstable mess. It was ultimately a full OS rewrite that fixed the platform.

---

I'll make a separate case too, for a rewrite I wish would happen: it's all well and good for Slack to build their client in Electron as a small startup that needs to experiment and iterate quickly. However, Slack is now a reasonably-sized public company, and they (should) have a stable product that will not undergo rapid changes.

Now would be an excellent time for Slack to rewrite their client to be a native app on each of the major platforms. They have the resources to create a snappy, performant app that more customers will enjoy using.

Problems can include:

- lack of parallelism, designed with single core CPUs in mind

- lack of security, software was designed for single user, offline operation turned multi-user and online

- "wrong" optimizations, for example relying on a lot of precomputation when people now want to change everything on the fly and modern computers allow it if the software is properly designed

- relying on outdated tech, like Flash

None of the previous points involve bad design, but things change, including user expectations. For now, security is a big one. It wasn't a big deal back then, for example, in a game console, a buffer overflow in a game would just cause a crash and piss off the player in some extremely rare case. Now because your console is online and so is your bank, the same relatively harmless bug on the same game can be used to siphon your bank account.

Bad reasons: "The code is messy", "It's written in language foo while all the cool kids are using language bar these days", "It's slow".

Good reasons: "The architecture is too tightly coupled now and it won't scale without untangling major pieces anyway", "The lack of our forward velocity is directly related to problem XYZ in the code, and here is how a new architecture would fix that."

In other words, I feel like I can sniff out bad rewrites now, which are generally lack a sense of focus and a true, enumerated list of problems with the current code base. Good rewrites have clearly delineated benefits that the rewrite will bring, stuff that brings measurable value, and show that the rewrite will bring things better and more cheaply than what's possible with the current codebase.

I think there are definitely counter-examples. Can you imagine using an OS in 2020 based on incremental improvements in Mac OS System 9, or Windows ME. Or browsing using a browser based on incremental improvements in Netscape 4.7?

The GEOM subsystem is FreeBSD is an example though that sometimes the world changes in a way that you can't accommodate and you have to go do a big bang reset.

Because of that, FreeBSD has a much nicer set of methods for dealing with disks and hotplugging and resizing ... while Linux is still all very ad hoc.

Some of the problems came only to light, because the original software was written and showed weaknesses. Of course afterwards one always knows more.

Then there is the reason of software often not perfectly matching your use-case and you could have better, specialized for your use-case software. You might also have other ideas about how extensible and modifiable your software should be. There really is a lot of software out there, that barely works for its use-case. If you are asked to extend that, good luck with that, without introducing new bugs, due to inflexible design.

So there are very valid reason for rewriting and often you do know better, how to write the software for your own use-case.

There's an inherent complexity in the problem being solved.

And there is an "accidental complexity" in the implementation of the solution.

Throwing away everything, people typically believe that they can avoid handling a lot of the "inherent complexity." But typically there is a good reason why the inherent complexity was addressed in the previous version of the program, and there's a big chance that the new "from the scratch" designers will have to relearn and rediscover all that, instead of transforming the already existing knowledge that is encoded in the previous version.

For anybody interested in the topic, I recommend the number of case studies presented in:

https://www.amazon.com/Search-Stupidity-Twenty-Marketing-Dis...

"In Search of Stupidity: Over Twenty Years of High Tech Marketing Disasters"

See about new rewrite of Wordstar simply not having the printer drivers that the previous had, and also other features people already expected, leading to Wordstar's demise.

Or what Zawinski's names "Cascade of Attention-Deficit Teenagers" (search the internet for that, the link here wouldn't work!)

"I'm so totally impressed at this Way New Development Paradigm. Let's call it the "Cascade of Attention-Deficit Teenagers" model, or "CADT" for short."

"It hardly seems worth even having a bug system if the frequency of from-scratch rewrites always outstrips the pace of bug fixing. Why not be honest and resign yourself to the fact that version 0.8 is followed by version 0.8, which is then followed by version 0.8?"

Or an interview with Jamie Zawinski from Siebel's "Coders at Work."

https://www.amazon.com/Coders-Work-Reflections-Craft-Program...

... "even phrasing it that way makes it sounds like there’s someone who’s actually in charge making that decision, which isn’t true at all. All of this stuff just sort of happens. And one of the things that happens is everything get rewritten all the time and nothing’s ever finished. If you’re one of those developers, that’s fine because there’s always something to play around with if your hobby is messing around with your computer rather than it being a means to an end — being a tool you use to get whatever you’re actually interested in done."

If one is able to cover all the complexity, and it is not destructive to the goal, the rewrite is OK. Otherwise, one should be critical to the ideas of rewrites as they could be potentially secretly motivated by simple (jwz again): "rewriting everything from scratch is fun (because "this time it will be done right", ha ha)"

I think rewriting to a new architecture piecemeal is probably easier than in a big bang - assuming the thing is at all complex and you can't actually understand all of it at once. The difference is more one of perception. It's easier to see the costs of the Frankenstein architecture than the rewrite, so we overestimate the costs of the former and underestimate the latter.

The real case for a rewrite is if you honestly think all that old stuff really has mostly just sentimental value; i.e. that it's OK to break all kinds of workflows because there are enough alternatives. If you can sell actual users on relearning all their habits, you can get away with a lot.

Considering they're two entirely different frameworks, Google did a good job creating a usable compatibility layer. This allows a relatively painless "ship of Theseus"-style transition where you have a combination of Angular and AngularJS components interacting with each other, until eventually it's just Angular components and you can drop AngularJS from the build.