This argument (don't re-write) sounds great to laymen and managers because they see "the code" as the sole artifact of the development effort. The flaw here (known to almost any developer) is that the code itself, the physical files and such represents the work of developing an application as completely as a photograph of a boxing match represents boxing itself.
Evidence of this can be seen in the many examples of companies "buying out" an application by taking only the source and attempting to run with it. The results are rarely, if ever, spectacular.
Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program. Why? Because by the end of the project you know more than you did at the beginning, and when you re-write the code from scratch you can leverage this knowledge on all of the code, not just the code you wrote after you learned these lessons.
In this way it is impossible to re-write something (unless you are starting with new developers as well), just like if you asked Stephen King to re-write (as in, re-type) The Shining...
"Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program."
Well, not always. What about the edge cases the developer has long since forgotten? Unless you've also got a good test suite that covers those cases, you're exposing yourself to the risk of missing those edge cases in a sans-source re-write.
You're absolutely correct. However I would argue that, if you are in a situation where the developer (developers, development team, etc.) is no longer is aware of these edge cases, you have bigger problems than a shipping delay due to a re-write.
But one of Joel's points is that, by the time you get around to rewriting something, you usually aren't dealing with the same programmers.
If this isn't the case, and you have the same core team available, then I agree, it is sometimes better to rewrite. But these days, refactoring techniques and testing methodologies are much more concretely defined and practice, so it still may be possible to essentially "rewrite" the code without having an X year shipping delay.
Agreed, this is why small, dedicated teams (for example, those with skin in the game in regard to the company's success) is the best insurance against this unfortunate scenario (loosing the original developers).
I agree. So essentially the "rust" in a codebase is the differential between what your developers know about the code and what knowledge is embedded in the code. Since it is much harder to read code than write it (at least, for "awful" codebases), once code has rusted enough it is best to just throw it away.
On the flip side, if you are able to keep your developers up to date on the codebase, you will save yourself a lot of trouble.
It's interesting to look back on this classic JoS article, with the perspective that Mozilla's rewrite-from-scratch basically kept the organisation around long enough for Firefox to come along, and look where that went. If Netscape hadn't made the decision to rewrite, they'd have released a browser even less well-suited for the then-modern Internet than Netscape 4 was when it came out, they'd have sunk even quicker, and there would have been nothing worth salvaging from the corpse - no Mozilla Foundation, no Suite, and ultimately no Firefox.
Surely this is only really valid point if Friefox saved Netscape? Is the most pressing concern of a owner/shareholder/employee that a company starts a successful open source project? No, it's food on the table! It didn't save most people's job.
Joel's point is still valid, commercially it was suicide. 3D Realm's constant rewriting of Duke Nukem Forever bottom up is another topical reminder of just how stupid it is. Another dead company.
Yeah, If you are being bogged down by legacy code and increasingly falling behind competitors due to slow innovation, it makes sense to do a rewrite. Mozilla had nothing to lose by a rewrite and everything to gain. In the short term they suffered immensely falling behind even more but in the long term it helped them emerge stronger.
It is the same with Classic Mac -> OSX. The former was crumbling under its own weight but OSX enabled Apple to out innovate others.
The key point is that a rewrite should always produce something better and leaner. Two cases where it didn't happen are
The rewrite wasn't a clear loss -- especially if, as the postmortem suggests, there was exactly one person who was capable of modifying the old codebase. (Likely this is the same person being quoted in Bill Clementson's article, which suggests some amount of ownership bias. Come to think of it, the same could be said of the ViaWeb case...)
This article has not dated well at all. Compare IE's security track record with, er, just about any other browser and it's clear that sometimes throwing away a teetering house of cards and starting again is absolutely the best thing to do.
It does count, they may have started with FreeBSD but they also had to write/rewrite a ton of stuff and throw away APIs and introduce new ones. I think the FreeBSD code is only a tiny (but critical) part of OSX
The part you're overlooking is that NeXT was as attractive to Apple as it was because they had a series of high-profile failures to develop a replacement OS in house.
In Apple's case the re-write idea turned out horribly and the only reason they made it thru is because a former founder had created a startup years earlier and had a working OS that Apple could buy and use.
Apple is hardly a poster child for re-writing software.
It's a delicate point, because on this one Joel is both right and wrong, depending on the circumstances. He's absolutely right that the "Big Rewrite" is a very dangerous proposition that should be assessed very carefully, but sometimes, it is the right choice.
I'll agree that in 95% of the cases it's not the right choice, though. We programmers do love us a good rewrite, even when it's bad for us. Incidentally, the Mozilla rewrite was probably in the 5% where it did make sense.
I think a fair interpretation is if you have both conditions:
1. Is the whole code base a maintenance nightmare?
2. Do we have to change all of it right now?
Which occurs, rarely. Most of the time a mechanical transform (e.g. Emacs macro) helps with the annoyances and standards. The rest, a deep refactoring is needed.
Frankly, dumping the source and starting from scratch sounds a little like running away from your problems instead of attacking them head-on.
When you see advice containing words like "never" and "always" and "just" you need to take that advice with a HUGE grain of salt.
Joel's point stands - rewriting for the sake of rewriting is frequently a mistake. I know it was a huge mistake in the case of Delicious 2, for example. But that doesn't mean that starting from scratch is ALWAYS a mistake, etc, etc.
As a programmer and as a manager of a product, I think you basically need to try a bunch of things and get burned a bunch of times to properly learn when and where to do things.
I find it a little disturbing that "hack" was one of the censor words, especially since it has a very specific meaning when appearing in source code (and many commenting tools even do special processing when it sees this word.)
Funny he implies the bundling of IE in every copy of Windows and the threats against OEMs who thought about bundling any other browser had nothing to do with the failure of Netscape.
It's true Netscape 4 lasted very long and was tough to improve, but I think that blaming Netscape for not having resources comparable to Microsoft is not entirely fair.
A rewrite is a risky proposition and should not be taken lightly. If Netscape did something wrong it was not to do it right after 4's launch.
Funny he implies the bundling of IE in every copy of Windows and the threats against OEMs who thought about bundling any other browser had nothing to do with the failure of Netscape.
"When Microsoft released Internet Explorer 3.0, fast on the heels of IE 2.0, it was shocking just how good a job they had done. Not only did they replicate every feature in Netscape's browser, but they added some more features too, and did it all with an architecture that was robust and strategic. While it is true that Microsoft used its operating system to help push its browser, it is also true that they just wouldn't have gotten away with this if their browser wasn't great. (Case in point: even though Windows out of the box can play MP3 files, everyone I know uses WinAmp, not the Windows Media Player, to listen to them. Even though MSN is on the desktop, everybody uses AOL. Back when the browser integrated with Windows was crap, Netscape had 80% market share. So please stop fretting about the power of bundling.)"
Everybody _he_ knew used WinAmp (in a time WMP was completely either useless or non-existent). About 40% of the people I know and work with would not touch Windows with a pole. Those do not make a significant cross-section of the market. Just like most people just lives with the OS their computer came with, most people just live with the browser that is installed by default either by the manufacturer or by their corporate overlords.
IE3 was the first "good enough" browser that came from Microsoft and, from 98 on, IE came bundled. For those who do not live in and for the web, "whatever comes with the computer" is what gets used. That was the last nail in Netscape's coffin.
For those who do not live in and for the web, "whatever comes with the computer" is what gets used.
MSN wasn't anywhere near as popular as AOL. But why not? After all, it satisifed your criterion, because it "came with the computer."
Also, MSN chat is nowhere near as popular as AOL Instant Messenger
Microsoft Money (bundled with my computer) isn't as popular as Quicken.
Microsoft Works isn't as popular as Microsoft Office.
and on and on and on...
The only way bundling matters is if the program being bundled falls into the category of "Good Enough" for the user in question. IE satisfied this criterion; MSN did not.
And, BTW, "this is the kind of thing you solve in five minutes with a macro in Emacs" looks almost like Joel Spolsky knew the HN crowd would eventually come...
This is Webkit + V8 + minimalism + usability (and other really good ideas like comics promotions), so, only V8 is what was written from scratch.
This is very good example of really smart approach. Another one is the reuse of Java/Eclipse ecosystem for Android development, same as Google App Engine Java. In both cases they rewrote VMs.
Evidence of this can be seen in the many examples of companies "buying out" an application by taking only the source and attempting to run with it. The results are rarely, if ever, spectacular.
Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program. Why? Because by the end of the project you know more than you did at the beginning, and when you re-write the code from scratch you can leverage this knowledge on all of the code, not just the code you wrote after you learned these lessons.
In this way it is impossible to re-write something (unless you are starting with new developers as well), just like if you asked Stephen King to re-write (as in, re-type) The Shining...