Hacker News new | ask | show | jobs
by Wowfunhappy 2170 days ago
I think I mostly agree with your take, but if I could defend the counterargument for a moment, there exist stronger cases for a rewrite than "we're smarter than those other guys." Namely, what happens if your requirements have fundamentally changed?

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.

2 comments

But didn't Apple actually attempt a full rewrite of the Mac OS which eventually failed? So instead they bought an already working OS and adapted it for their purpose.
Well, as I'm thinking of it NextStep was still effectively a "rewritten from scratch" OS—it just happened to get written outside of Apple.
That is not what Joel means by rewriting from scratch. NextStep was not written to replace Mac OS, it was just later adapted into that purpose. It is a completely different scenario.
Oh yeah. I remember that clearly. It was Copland- er, MacOS 8.

What a cluster----. Back then, crashes would result in a special kind of debug screen called MacsBug[0].

When you walked into their "release-ready, hands-on lab," almost every screen was displaying MacsBug.

The change didn't actually happen until NextStep became Cocoa.

I was also at a Microsoft "Longhorn" prerelease event. They were showing "live code demos," but you could clearly see the presenter quitting Director, when they were done with their demo.

That became Vista, another famous success story (but at least, it did ship).

[0] https://en.wikipedia.org/wiki/MacsBug

From wikipedias Copland article (https://en.wikipedia.org/wiki/Copland_(operating_system)):

"The Copland development effort is associated with empire-building, feature creep, and project death march. In 2008, PC World named Copland on a list of the biggest project failures in IT history."

"what happens if your requirements have fundamentally changed?" That's not a rewrite, that's a new program with the same name
What happens is that you write the first version, and then the requirements fundamentally change (or you learn that your requirements were fundamentally wrong) but it happens gradually and you change and change the old version. It's now mostly meeting the new set of requirements, but has a bunch of cruft from what it used to do.

Throwing that away and writing something to support the new set of requirements is a rewrite.

I take no position, here, on whether it should be done.

I would recommend just removing the cruft rather than throwing everything away. But cruft should really be removed continuously.
I was merely being descriptive, clarifying that there are not uncommon situations where requirements have changed and yet nonetheless one of your options is aptly termed a rewrite.

If I am to move into making recommendations, then I think the whole thing is ultimately situation dependant, but that your advice is correct for the most common cases.