Hacker News Reader

Comment by statictype | Hacker News Reader

Joel Spolky wrote a popular essay on why you should never do The Big Rewrite. I mostly agree with it but it's not always clear cut (Mozilla - his example in the essay - eventually got re-written as the most popular browser in use today)

It's a difficult decision to make, the choice between improving an existing code base that has grown warts against the temptation of starting fresh and fixing what went wrong the first time, under the guise of learning from past mistakes.

I guess the lesson is: Don't try to rewrite your codebase from scratch unless you understand that you will spend an order of magnitude more time on the rewrite, even factoring in the experiences you have gained from doing it once.

View on HN

From scratch? Like, rewrite all your libraries and nifty little UI tricks? Of course not.

But sometimes ripping out the plumbing and throwing the bigger pieces back together works wonderfully.

I guess that's called refactoring, though. :)

The point I'm getting at is, who does The Big Rewrite? I can't ever see myself wanting to rewrite sections of code that are working perfectly fine Just Because.

How much of The Big Rewrite was Mozilla? Did they literally rewrite everything? I can't imagine so. I bet they kept a LOT of code. It was probably more along the lines of a rather daunting refactor.

I'm just wondering what "starting fresh" means. For me, it normally means fixing architectural decisions that have become a huge pain in the but I'm keeping a LOT of the code base.

Refactoring, as talked about in Martin Fowler's book and by people who've done academic work on the subject, consists of changes that alter the structure of code while preserving functionality.

In many environments, specific refactorings are pre-packaged, such that they know their preconditions for working properly, and work with almost mathematical precision. In these sorts of environments, with additional support like Unit Tests, you gradually morph from one structuring of the system into another. This can be a lot safer than "ripping out the plumbing and throwing the bigger pieces back together." (I've also done the rip/reassemble thing. It's often fun and yields good results too.)

I've done very large rewrites from scratch successfully and I've done very large rewrites incrementally successfully. I think it can happen just fine.

Of course, doing that as a one-man team with a closed-source commercial product that you have promised to give away for free doesn't seem like the kind of thing that can get done.

Mozilla - his example in the essay - eventually got re-written as the most popular browser in use today

It worked out ok for end users, but didn't lead to such a great outcome for Netscape.

Well, I think the rewrite occurred after the codebase was open-sourced.

Firefox's rendering engine, Gecko (née NGLayout) was started well before Netscape went open source. Mozilla.org decided to scrap the classic rendering engine in favor of Gecko/NGLayout within a few months of going open source. Six short years after that, Firefox was ready for prime time.

http://www.mozillazine.org/articles/article177.html

http://www.mozilla.org/newlayout/screenshots/

Reply on news.ycombinator.com