Comment by hn_throwaway_99 | Hacker News Reader

Comment by hn_throwaway_99 | Hacker News Reader

Parent Full thread

hn_throwaway_99

Regarding #1, this is now an often touted recommendation, even by folks like Joel Spolsky whom I greatly admire, but I'm not sure it's the right lesson. For example, I know that Google (at least in the 00s) rewrote huge, major pieces of their infrastructure multiple times and did so successfully. While I agree that broadcasting out a message of "We're going to stop the world and add no new features until we do a ground-up rewrite" is a bad idea, perhaps other lessons could be:

1. Don't write code that's such a spaghetti mess in the first place that you feel the need to throw your hands up and say "nothing can be done except a rewrite".

2. If you do need to do a major rewrite, make sure you have the ability to staff two teams - one doing the rewrite and another maintaining and adding new features to the existing product.

3. Kinda related to number one, but if you have well-organized code to begin with I find it's much easier to do a major rewrite in "sections" (though there are obviously difficulties with this approach).

> rewrote huge, major pieces of their infrastructure multiple times and did so successfully

I think that's different from a user facing rewrite. I suspect while Google did its infrastructure rewrites, users didn't notice a difference. Additionally, Google probably had the resources to continue delivering features to users while the infrastructure was being developed.

The problem with a front end rewrite is (a) things might break and users will notice, and (b) it's hard to deliver new features to users while the front end app itself is being rewritten.

Google isn't the only example here. Heck, just look at the transition from Classic MacOS to OS X. I definitely think Apple would have been dead long ago if they said "A rewrite is too expensive/risky, let's just incrementally improve Classic MacOS".

I guess my point is that there are right ways and wrong ways to do ground-up rewrites, and the fact that a lot of people do them the wrong way shouldn't mean the lesson should be to never do them.

Replacing one mature operating system with another, which itself was based on one even more mature, and adding stuff is not quite a rewrite. That was more like how Microsoft moved NT into its consumer OS. It was a bit of a mess but had a clear payoff once everything was updated or obsoleted. NT and BSD were both battle-hardened long before anyone thought to put them in consumer systems.

Apple actually tried to rewrite the classic OS from scratch with the Copland project and it failed (at enormous cost). OS X was not a rewrite-from-scratch since they acquired an already working OS from Next. The had to add compatibility layers (which was in itself a major undertaking) but they didn't write the OS from scratch.

Spolskys point back then was that you couldn't stop the world, do nothing for two years and then come back with your rewritten product.

It was not that you couldn't rewrite part of the product here and there over time, and end up with something that is only the same as the original product in the way the greek ship was.

4. If you're going to do the rewrite, don't take many years working on it, just to release a broken product missing lots of core features.

5. If you're releasing a broken product missing core features, don't take many YEARS after release to un-brake your product and build some of the missing features again.

Reply on news.ycombinator.com