August 15, 2008
Another argument against rewrites
I read an interesting post about the launch of Delicious 2.0. When Yahoo! bought del.icio.us, they immediately rewrote the entire site in a new language (two, actually). The rewrite took three years, didn't add significant functionality, broke some old functionality, and introduced a bunch of new bugs — even after three years.
As Delicious stagnated, an entire ecosystem of social bookmarking sites sprang up. Delicious squandered its huge lead in this space doing a rewrite, while it could have used that energy to keep innovating ahead of the me-too sites.
Let this be yet another lesson in avoiding the big rewrite. Even if the codebase you inherit is really bad, if you've got a working system (which del.icio.us most certainly was), it's best to keep the existing system and refactor.
The rewrite is a seductively attractive solution. Just looking at the code makes your brain hurt? Dump it and start over! I've gone through my share of rewrites. I re-wrote my application Felix from the ground up twice. The first rewrite was needed — I wrote the first version while simultaneously learning C++ and Win32 programming — but the second could and should have been avoided.
I'll use the delicious debacle as another reminder that no matter how attractive the rewrite options seems, it's almost always a bad idea.
Incidentally, it's been pointed out that Yahoo! rewrote the original perl codebase into php and C++ (!), because those are its "institutional" languages. It sounds like Yahoo!'s inflexibility caused it to make a huge blunder.
As I understand it (and I might be wrong), del.icio.us (yeah, I’m old-school like that) was something Josh Schachter pretty much threw together as a pet project, that was never designed to hold up to the scale it was called on to support. It was tweaked to keep up, but was never on a very firm footing. I also get the impression he lost interest in maintaining it after selling out, which isn’t too surprising.
Yahoo’s rewrite clearly was days late and dollars short, but in del.icio.us’ case, it may have needed some kind of rewrite anyhow.
By all accounts, the delicious codebase was a mess. A refactoring might have ended up changing or removing every single line of original code.
The difference between that and a rewrite, however, is that with refactoring you start and end with a working system. You can also maintain and improve the system as you go.
There are lots of problems with rewrites, which Chad Fowler explains very well here. Yahoo! committed one of the cardinal sins of rewrites: duplicating the system and adding functionality at the same time. But I guess if your rewrite takes three years, that’s a hard temptation to resist…
In reading this article, I was immediately reminded of a very similar one I read more than eight years ago, Joel on Software’s post “Things You Should Never Do, Part I“. I think the example Netscape provides is even more compelling than that of del.icio.us, although admittedly not as contemporary.
@Sako
Yeah, the Netscape is one of the classic examples of a rewrite gone bad. I think the problems with rewrites first became widely known with The Mythical Man Month by Fred Brooks. It seems incredible that so many of the problems he identified in software development are still endemic in the industry over 30 years later.