[mjw1007]

Joel is making two separate claims there, though he doesn't cleanly distinguish them.

One is that rewriting from scratch is going to give you a worse result than incremental change from a technical point of view (the « absolutely no reason to believe that you are going to do a better job than you did the first time » bit).

The second is that independent of the technical merits, rewriting from scratch will be a bad commercial decision (the « throwing away your market leadership » bit).

We now know much more about how this turned out for his chosen example, and I think it's clear he was entirely wrong about the first claim (which he spends most of his time discussing). Gecko was a great technical success, and the cross-platform XUL stuff he complains about turned out to have many advantages (supporting plenty of innovation in addons which I don't think we'd have seen otherwise).

It's less clear whether he's right about the second: certainly Netscape did cede the field to IE for several years, but maybe that would have happened anyway: Netscape 4 wasn't much of a platform to build on. I think mozilla.org considered as a business has done better than most people would have expected in 2000.

[aidenn0]

In Joel's defense, we don't know that gecko is better than X years of incremental changes to Netscape 4.

One of the big issues with software engineering advice is that it is really hard to find apples-to-apples comparisons for outcomes.

[mjw1007]

True.

I think we can say that Gecko ended up technically better than incremental changes to Internet Explorer, which I think was starting off from a more maintainable codebase than Netscape 4. That's hardly conclusive but it's some evidence.

[aidenn0]

Indeed. My intuition based nothing other than my subjective experience is that there are times that throwing away the code is the correct decision, but they are a rounding error compared to the times that people want to throw away the code, so to a first order of approximation "never start over from scratch" is correct.

Simply shifting the burden of proof to the "rewrite" side is usually sufficient. Where I currently work a rewrite request is not answered with "no" but "show me the data." 90% of the time the requester doesn't even try to gather data, the other 10% of the time results in some useful metrics about a component that everyone agrees needs some TLC, whatever the final decision.

[lucideer]

> we can say that Gecko ended up technically better than incremental changes to Internet Explorer

> ...

> That's hardly conclusive but it's some evidence.

Given Internet Explorer's monopoly position, and consequent disincentive to compete, it's not really the best comparison.

Compare to something like Opera Presto, a codebase that - while younger than Netscape - predates Internet Explorer, which underwent incremental changes while remaining in a minority market position. It was killed by market forces, but I doubt anyone would contest it was a badly put together piece of software in the end.

Konqueror is another example. It's not quite as compelling, as KHTML itself has fared less well than its forks, Safari WebKit has never exactly been a leader in engine advancement, and Chrome's innovations, while incremental, were largely built on a scratch-rewrite-and-launch-all-at-once of one component (V8). However KHTML/Webkit/Blink is still pretty much an incremental rewrite success story.

[iopq]

I actually used Opera because it allowed me to stop websites from hijacking my browser. No capturing my right click or any of this silly bullshit. The exact UI/features I want. Opera 6-12 were good times.

[olavk]

Yeah but Microsoft let IE stagnate for half a decade after it had achieved dominance. There were 5 years between IE 6 and IE 7. If MS hadn't disbanded the IE team but had kept up the pace of incremental development, I very much doubt Mozilla would have ever been able to catch up again.

I would say Joels point still holds in the general case where you you can't count on competitors to just stop developing their product until you have achieved parity again.

[mjw1007]

IE6 was released about the same time as Mozilla 0.9.3. I think Mozilla was already ahead in technical terms at that point.

Certainly it had better CSS support, and on my machine it crashed less.

The important difference was a matter of support for "official" standards against support for "best viewed in Internet Explorer" sites.

[pawelk]

And, as far as I know, Microsoft has developed Edge from scratch after all. The years of incremental updates to IE are now maintained for legacy support.

[robin_reala]

That’s incorrect. Edge is still Trident, but they took the opportunity of a change in name to rip out all of the old backwards-compatibility layers and leave just the modern stuff.

[Jweb_Guru]

> In Joel's defense, we don't know that gecko is better than X years of incremental changes to Netscape 4.

Yes, we do, as does anyone who was following browsers at the time. They tried to incrementally improve Netscape 4 and it was a disaster.

[hinkley]

I disagree on item 1. My basis for this occurred to me on a contract a few years ago, as I was being scolded for fixing things instead of letting them be because “we’re going to do a rewrite soon” (even though the boss that promised this got promoted out of the org).

The promise of a rewrite institutionalized accumulating technical debt. When it comes time to do the rewrite, everyone starts out on the wrong foot. The big rewrite is a lot like New Years resolutions. They don’t stick, they cost money and time, create negative reinforcement and sometimes people get hurt.

Refactoring institutionalizes continuous improvement, thinking about code quality, and yet discourages perfectionism because you can always fix it later when you have more info. My theory is that people good at refactoring can handle a rewrite well. Maybe are the only people that can handle a rewrite well. But if you can refactor like that you don’t need a rewrite (or rather, you’ve already done it and nobody noticed).

[evincarofautumn]

I think there is something to be said for the technical & market advantage of “rewrites” in the sense of “very ambitious but still incremental refactorings”. Literally rewriting all the code from scratch is likely to be a mistake, but there’s a spectrum from “edit” through “refactoring” to “rewrite”, and it can pay to push toward the more aggressive end of that spectrum sometimes, if you know precisely what you’re doing.

That is, some of my projects (personal & professional) have benefited enormously from designating the old version as a “prototype”, creating a “new” project with slightly different architectural decisions based on the deficiencies of the old version, copying most of the code from the old version to the new, and filling in the details.