4 ms·

Why We Threw out All Our Code (And Why You Should Too)

92 points by sthatipamala 15y ago

kayoone 15y ago
Especially when getting into a codebase that is not yours you are tempted to think "why dont i just rewrite this in a better an cleaner way". Then you go on todo that and fall into most of the pitfalls the original author fell in before, have to rethink every idea behind and it usually is alot more work than you think. That said it depends heavily on the size of the project and a bunch of other things, for a 3 month old project it might make sense.
nfm 15y ago
I've never used NowJS nor looked at the source for it, so I can't comment about their justification for a rewrite. But most programmers I know don't need any encouragement to rewrite stuff, myself included!
- boyter 15y ago
  That's the attitude I am trying to avoid these days. When I look at something that I want to rewrite I now ask the following questions, 1. Do I have sufficient tests and testing to do this without breaking things? 2. Do I want to want to rewrite because I cant be bothered understanding it? 3. Is there going to be any gain now or in the near future by rewriting it? 4. Will I be able to rewrite it sometime in the future as part of another piece of work which actually delivers value? Unless I come up with Yes, No, Yes, No I tend to leave it alone. There are other things of value I can do with my time. EDIT - Formatting...
  - mvzink 15y ago
    Thank you, these criteria just saved me from tearing down a building.
Someone 15y ago
It's managed to survive our vicious benchmarking tools and our ridiculously comprehensive test cases. I guess they did not rewrite those from scratch. If so, I would guess they only rewrote, at the most, 25% of their code.
Volpe 15y ago
They threw out 3 months of work... That's not a rewrite, that's a prototype. People do this all the time.
- josephcooney 15y ago
  +100 - the biggest questions (to me) were HOW MUCH code did they throw out, and how old was it? Throwing out a few months of code you just finished writing (and which you're still intimately familliar with) is vastly different to throwing out a code-base that would be entering middle-school if it was a person.
  - neilk 15y ago
    I don't know what the old codebase is like, but the current one is just 2145 LOC, not counting tests. 62K total. I know that startups do way more that just write code, so I'm not criticizing them at all. And it seems they're not afflicted with the typical engineer modesty when it comes to their own codebase, which is a good thing. On the other hand it's not exactly a superhuman hacking achievement to rewrite this from scratch.
    - Cushman 15y ago
      So if we're charitable and say the new codebase is, oh, three times as compact, that means they threw out about 10% of their code.
Swizec 15y ago
Rewrites are always fun and I applaud any man brave enough to undertake such an effort. I've often been faced with a situation warranting a rewrite, but I never mustered the courage to actually go with a full rewrite I don't think. Gradual rewrites are much more my thing.
- FuzzyDunlop 15y ago
  I've been really really tempted to do one, but sadly the pressures of the job take precedence and so it usually ends up being the case that you stick with the code you've got and try and hack extra things in, knowing full well you really don't want to and aren't at all happy with it. So my 'rewrites' sometimes come in the form of superficial organisation. Looks moderately nicer, doesn't work any better. I guess it is courage though. You don't really know that your rewrite will be an actual improvement, or if you'll even pull it off. Brave move indeed.
raldi 15y ago
Throwing out all your code and rewriting it from scratch is like demolishing your building and constructing a replacement from scratch. It's usually not the right thing to do, it occasionally and rarely is the right thing to do, and it's always the tempting thing to do. It's stupid to argue, "You should never tear down a building" (like http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html implies) and it's also kinda stupid to write an article entitled, "Why We Tore Down Our Building (And Why You Should Too)" Neither is universally right. The right thing to do in a given situation is a difficult and complicated question to answer, and it depends on the building in question: how big it is, how well it was designed, how well it's been maintained, etc.
- praeclarum 15y ago
  Right. In this case it was 3 months worth of code. I think the analogy is closer to "we tore down this clay hut we built". Easy to build, easy to tear down. If this were a mature code base, I would be a little more shocked.
  - Cushman 15y ago
    Or maybe closer to "We're putting this model building in the closet since we built the real one."
- badclient 15y ago
  How often do you build a prototype building? Or a building as a side project? Your analogy fails, sir. It's easier and more common to write dirty code that functions as it should than build a building with poor foundation but that looks and functions as it should.
  - raldi 15y ago
    People build temporary structures all the time -- event tents, for example. And plenty of people finish a room, redo a bathroom, build a treehouse or a shed, etc, as a side project. And believe me, it takes a high level of expertise to inspect a building. Many of the most important kinds of flaw are only evident to the eye of an expert.
chegra 15y ago
Relevant: Things you should never do - http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html
- deleted 15y ago
  [deleted]
benologist 15y ago
Throwing it away is easy when there's not that much of it. My codebase is 10s of thousands of lines, it evolves as I get better but I'm not going to scrap it.
jjordan 15y ago
sigh; a headline like this is little more than HN linkbait. As others have mentioned, throwing out all your code is generally a bad idea, especially if your project is of significant size. How many lines is NowJS anyway? I doubt it was much of a loss.
- dstein 15y ago
  I'm still trying to figure out what NowJS does other than expose an RPC call using socket.io. All of the features on the website are actually socket.io features.
ctide 15y ago
3. Sunk costs and egos get in the way of good software Egos are what drive people to throw away their entire codebase and start over.
- pyre 15y ago
  Depends on the angle. The person that wrote the codebase is usually the one holding onto the old codebase due to ego. On the other hand, new people that come in and don't like things can be full of ego in the sense of, "I could program this better without any limbs!"
  - ctide 15y ago
    Egotistical engineers always think this time things will be different, because they're smart enough to do it right. The reality is that every rewrite brings a new and different set of problems that need to be addressed. You don't escape problems by scrapping it all and starting over and this is one of the most valuable lessons to learn as an engineer.
    - andrewflnr 15y ago
      You don't need to be egotistical to see that you can do things better the second time around because you've learned stuff along the way. In this case, the writer provided multiple examples of how they were able to use the lessons they'd learned from the old codebase to improve the new one. They did, in fact, escape some of their problems. Did they introduce new problems? I'm sure they did, but they're probably still better off overall. Sometimes ego is involved, but sometimes rewriting is just the rational thing to do from a cost/benefit standpoint.
- rickmb 15y ago
  Egos and lack of skill. It's so much easier to write from scratch than it is to refactor. So many programmers have no idea how to tackle an existing codebase, even if it's one they've wrote themselves.
  - 15y ago
astrofinch 15y ago
It's probably easier to do this sort of rewrite if you've already got "ridiculously comprehensive test cases". Anyway, congrats on 0.7 Sri!
d2 15y ago
Netscape 6 is (or was) the oft quoted example of why not to do this. All that old code may seem old and boring, but it has a huge amount of knowledge, wisdoms, learnings, fixed mistakes, performance improvements, great ideas, deleted bad ideas and security fixes built into it. When you throw out your code you're throwing out all that knowledge on the assumption that you can build it all back with improvements. Evolving an application from a known good state to a known better state is usually the best approach unless your codebase is small or your app has no traction. Rewriting your app from the ground up is like getting divorced and dating a new girlfriend. The first few months are a lot of fun until you figure out how much you lost.
- quink 15y ago
  Without Netscape 6, we wouldn't have had Phoenix/Firebird/Firefox, and probably wouldn't have IE7, IE8, IE9 and KHTML/Webkit would have come about very differently and all these would have had much less competition. Netscape 6, or at least the mere fact that it existed and worked well enough and the fact that it was the first browser ever that did standards well and focused on not much else other than standards, made it the most important browser ever created. Netscape 6 was the most revolutionary browser project ever created and had the development effort behind Netscape 6 not been done, we would possibly have had a much worse very IE-only web today. Never mind that beyond all that, Netscape 4 was terrible and deserved to be thrown out.
  - shadowfox 15y ago
    > Netscape 6 was the most revolutionary browser project ever created I dont disagree with the general sentiment of your comment. But as someone who attempted to use Netscape 6 at various stages of its development, I fear that statement might be stretching facts a little bit.
steve8918 15y ago
Once you start making revenues from your code, a complete rewriting is probably the worst thing you can do for your company. Sometimes it might be warranted, but customers care about solving problems, not about technology. Chances are if you wrote properly modularized code, you can rewrite modules one by one, which is perfectly legit. But just dropping everything and trying to rewrite a product from scratch is a mistake that a company usually only makes once (before they die).
raganwald 15y ago
A few people have pointed out that it’s easy to throw out your code when you (a) have tests for it, and (b) only have three months invested in it. I agree with both of those points, but want to tip my hat to a team that rewrites their code after three months. The reason some code bases can’t be rewritten after a few years is because when the code was only three months old, the team passed on the chance to rewrite it while it was still a tractable exercise.
- grncdr 15y ago
  Very much agree. An extra layer on the danger cake (for web apps) is if your user base grows slowly while keeping the business profitable. Suddenly (sic) you hit real capacity limits after n years, and have no idea how the "organically grown" code in question works.
kellishaver 15y ago
I'm glad they're happy with the rewrite, but honestly, this makes me feel a bit nervous about updating my Node app utilizing NowJS to the 0.7 release. Maybe it is better. Maybe it is more stable, smaller, and faster, and well-tested. But it hasn't had as much "real world" use thrown at it as the previous codebase had. I'm not saying I won't upgrade, but I'll likely wait a bit until I do and stay with what I know works right now, at least in production.
brandonwang 15y ago
Please bear in mind the counter article everyone is citing (http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html) was written 11 years ago. I'm not saying that it's wrong because it's from 11 years ago, but you really want to consider its central example. Netscape 6.0 was a complete rewrite. The article claims that this was a mistake. Now, if you would recall, one of the reasons Netscape 6.0 was completely rewritten was to use Raptor/NGLayout. Raptor/NGLayout was later renamed to Gecko. Gecko is the currently developed Firefox rendering engine, and Netscape 6.0 marked the start of the Mozilla foundation. I would harshly argue that Gecko would not have taken off nearly as well without Netscape's rewrite. But this is definitely not a story about Gecko's popularity. It's about the reason why Gecko was the decision they took at the time, and the current impact of Gecko. Besides the fact that Gecko was one of the early open-source success stories, the reason why Netscape decided to scrap everything and start from scratch was simple: Netscape 4.0 was horrid. Remember back to the days of IE vs Netscape. Netscape was significantly slower, and had no dynamic HTML among many other features. It was buggy and would crash frequently. And the development on the "continuation" of 4.0 code was simply too slow to compete, because of outdated, not modulated code, and stuff stuck in that simply "worked," and never changed to allow for future changes. Now, people attribute Netscape 6 to Netscape's death because of this radical decision. But take a look at Netscape's usage statistics: http://upload.wikimedia.org/wikipedia/en/1/16/Netscape_Navigator_usage_share.png http://upload.wikimedia.org/wikipedia/en/1/16/Netscape_Navig... . Hey, guess when Netscape 4.0 came out and IE started to dominate? 1996-1997. By 2000, when Netscape 6 was released, Netscape's usage already dwindled down to nothing. Now, you're thinking, why didn't Gecko save Netscape? It takes too long to reverse these tides. Netscape was already dead. AOL acquired Netscape in 1998, to combat IE. Then, in 2003, AOL won an antitrust suit against Microsoft, and allowed AOL to use IE royalty-free. Netscape was pretty much scrapped at that moment because the damage had been done. But wait. Mozilla released Phoenix in 2004, based on Gecko. You should now the story from there. (Clue: Phoenix -> Firefox) Disclaimer: I'm not saying that Firefox > IE or Chrome or whatever. I'm saying that the codebase Netscape 4.0 was based on was doomed to fail. Gecko still lives on today, and was started as a rewrite of Netscape. Anyway, my point is, there are times to rewrite things, and there are times to keep them the same. If you have a good, legitimate reason to rewrite, as Netscape or NowJS did, you should. If you are just the stubborn programmer that always implements his own Queue or QuickSort when libraries exist, don't.
beck5 15y ago
An attention grabbing headline but all the same I have been using now.js and its been a great tool (although a cut down on the print statements would be nice).
makecheck 15y ago
Justified or not, I think a project owes it to its users to change major version numbers when a major rewrite (much less a complete one) has occurred. As perfect as your code might be, customers deserve a hint when major changes were done under the hood. Moving from 0.6 to 0.7 screams "just a few changes, some new features", not "we threw everything out and started over". This should have been made into "1.0beta", I would think.
- stephth 15y ago
  There are other factors involved when deciding a version number than the code under the hood: API changes, new features, is it production ready, 'this is the now stable API that we'll be maintaining for a long time', etc. Edit: for perspective, a thoughtful proposition on how to approach software versioning: http://semver.org http://semver.org
  - makecheck 15y ago
    I agree that there are many factors. I'm just saying that some changes are important enough to trump anything else; the presence of a rewrite should decide the version all by itself.
anirudh 15y ago
Its not always the right thing as there are years of issues/corner cases that have been resolved.
flocial 15y ago
Well, just because some prominent luminary says it shouldn't be done never means it's always a bad idea. A lot of the basis against rewrites are for relatively mature projects still on a high growth trajectory or large installation base. However, there are exceptions to that as well. Foursquare went from LAMP to Scala/Lift, PostgreSQL, and MongoDB with minimal complications and it's paid off handsomely to support their amazing growth. Also, the money quote: "It's managed to survive our vicious benchmarking tools and our ridiculously comprehensive test cases. " My assumption is they are using the same languages and tool sets (not porting from language X to Y). I'm curious as to how long the rewrite took though.
stretchwithme 15y ago
If you're dealing with human DNA, a complete code rewrite will likely fail. But if its just an amoeba and you have a lot of time, go for it.
shahan 15y ago
Whether their decision was right or wrong, they made a decision that big companies tend not to make. Startups should probably have a bias towards decisions like that.
jheriko 15y ago
I'd be dubious that they actually rewrote everything - having working stuff lying around that already worked, some of which was probably just fine, I'd hope it got copy-pasted into the new code...
adrianscott 15y ago
You should read the book, "In Search of Stupidity - Over 20 Years of High-Tech Marketing Disasters" Refactoring is almost always preferable to throwing out all your code, imho.
onan_barbarian 15y ago
Frequently, throwing out "all your code" is a sign you did pretty much everything wrong to begin with. Personally, the sign of a decent design is when you can wind up doing the old "Grandpa's Mattock" trick: "This is grandpa's mattock; my father replaced the handle and I replaced the blade".
nvictor 15y ago
Be ready to throw away your first version. I wish I had the right quote on hands. The K in K&R said that.

92 points by sthatipamala 15y ago

Especially when getting into a codebase that is not yours you are tempted to think "why dont i just rewrite this in a better an cleaner way". Then you go on todo that and fall into most of the pitfalls the original author fell in before, have to rethink every idea behind and it usually is alot more work than you think. That said it depends heavily on the size of the project and a bunch of other things, for a 3 month old project it might make sense.

nfm 15y ago

I've never used NowJS nor looked at the source for it, so I can't comment about their justification for a rewrite. But most programmers I know don't need any encouragement to rewrite stuff, myself included!

boyter 15y ago
That's the attitude I am trying to avoid these days. When I look at something that I want to rewrite I now ask the following questions, 1. Do I have sufficient tests and testing to do this without breaking things? 2. Do I want to want to rewrite because I cant be bothered understanding it? 3. Is there going to be any gain now or in the near future by rewriting it? 4. Will I be able to rewrite it sometime in the future as part of another piece of work which actually delivers value? Unless I come up with Yes, No, Yes, No I tend to leave it alone. There are other things of value I can do with my time. EDIT - Formatting...
- mvzink 15y ago
  Thank you, these criteria just saved me from tearing down a building.

Someone 15y ago

It's managed to survive our vicious benchmarking tools and our ridiculously comprehensive test cases. I guess they did not rewrite those from scratch. If so, I would guess they only rewrote, at the most, 25% of their code.

Volpe 15y ago

They threw out 3 months of work... That's not a rewrite, that's a prototype. People do this all the time.

josephcooney 15y ago
+100 - the biggest questions (to me) were HOW MUCH code did they throw out, and how old was it? Throwing out a few months of code you just finished writing (and which you're still intimately familliar with) is vastly different to throwing out a code-base that would be entering middle-school if it was a person.
- neilk 15y ago
  I don't know what the old codebase is like, but the current one is just 2145 LOC, not counting tests. 62K total. I know that startups do way more that just write code, so I'm not criticizing them at all. And it seems they're not afflicted with the typical engineer modesty when it comes to their own codebase, which is a good thing. On the other hand it's not exactly a superhuman hacking achievement to rewrite this from scratch.
  - Cushman 15y ago
    So if we're charitable and say the new codebase is, oh, three times as compact, that means they threw out about 10% of their code.

Swizec 15y ago

Rewrites are always fun and I applaud any man brave enough to undertake such an effort. I've often been faced with a situation warranting a rewrite, but I never mustered the courage to actually go with a full rewrite I don't think. Gradual rewrites are much more my thing.

FuzzyDunlop 15y ago
I've been really really tempted to do one, but sadly the pressures of the job take precedence and so it usually ends up being the case that you stick with the code you've got and try and hack extra things in, knowing full well you really don't want to and aren't at all happy with it. So my 'rewrites' sometimes come in the form of superficial organisation. Looks moderately nicer, doesn't work any better. I guess it is courage though. You don't really know that your rewrite will be an actual improvement, or if you'll even pull it off. Brave move indeed.

raldi 15y ago

Throwing out all your code and rewriting it from scratch is like demolishing your building and constructing a replacement from scratch. It's usually not the right thing to do, it occasionally and rarely is the right thing to do, and it's always the tempting thing to do. It's stupid to argue, "You should never tear down a building" (like http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html implies) and it's also kinda stupid to write an article entitled, "Why We Tore Down Our Building (And Why You Should Too)" Neither is universally right. The right thing to do in a given situation is a difficult and complicated question to answer, and it depends on the building in question: how big it is, how well it was designed, how well it's been maintained, etc.

praeclarum 15y ago
Right. In this case it was 3 months worth of code. I think the analogy is closer to "we tore down this clay hut we built". Easy to build, easy to tear down. If this were a mature code base, I would be a little more shocked.
- Cushman 15y ago
  Or maybe closer to "We're putting this model building in the closet since we built the real one."
badclient 15y ago
How often do you build a prototype building? Or a building as a side project? Your analogy fails, sir. It's easier and more common to write dirty code that functions as it should than build a building with poor foundation but that looks and functions as it should.
- raldi 15y ago
  People build temporary structures all the time -- event tents, for example. And plenty of people finish a room, redo a bathroom, build a treehouse or a shed, etc, as a side project. And believe me, it takes a high level of expertise to inspect a building. Many of the most important kinds of flaw are only evident to the eye of an expert.

chegra 15y ago

Relevant: Things you should never do - http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

deleted 15y ago
[deleted]

benologist 15y ago

Throwing it away is easy when there's not that much of it. My codebase is 10s of thousands of lines, it evolves as I get better but I'm not going to scrap it.

jjordan 15y ago

sigh; a headline like this is little more than HN linkbait. As others have mentioned, throwing out all your code is generally a bad idea, especially if your project is of significant size. How many lines is NowJS anyway? I doubt it was much of a loss.

dstein 15y ago
I'm still trying to figure out what NowJS does other than expose an RPC call using socket.io. All of the features on the website are actually socket.io features.

ctide 15y ago

3. Sunk costs and egos get in the way of good software Egos are what drive people to throw away their entire codebase and start over.

pyre 15y ago
Depends on the angle. The person that wrote the codebase is usually the one holding onto the old codebase due to ego. On the other hand, new people that come in and don't like things can be full of ego in the sense of, "I could program this better without any limbs!"
- ctide 15y ago
  Egotistical engineers always think this time things will be different, because they're smart enough to do it right. The reality is that every rewrite brings a new and different set of problems that need to be addressed. You don't escape problems by scrapping it all and starting over and this is one of the most valuable lessons to learn as an engineer.
  - andrewflnr 15y ago
    You don't need to be egotistical to see that you can do things better the second time around because you've learned stuff along the way. In this case, the writer provided multiple examples of how they were able to use the lessons they'd learned from the old codebase to improve the new one. They did, in fact, escape some of their problems. Did they introduce new problems? I'm sure they did, but they're probably still better off overall. Sometimes ego is involved, but sometimes rewriting is just the rational thing to do from a cost/benefit standpoint.
rickmb 15y ago
Egos and lack of skill. It's so much easier to write from scratch than it is to refactor. So many programmers have no idea how to tackle an existing codebase, even if it's one they've wrote themselves.
- 15y ago

astrofinch 15y ago

It's probably easier to do this sort of rewrite if you've already got "ridiculously comprehensive test cases". Anyway, congrats on 0.7 Sri!

d2 15y ago

Netscape 6 is (or was) the oft quoted example of why not to do this. All that old code may seem old and boring, but it has a huge amount of knowledge, wisdoms, learnings, fixed mistakes, performance improvements, great ideas, deleted bad ideas and security fixes built into it. When you throw out your code you're throwing out all that knowledge on the assumption that you can build it all back with improvements. Evolving an application from a known good state to a known better state is usually the best approach unless your codebase is small or your app has no traction. Rewriting your app from the ground up is like getting divorced and dating a new girlfriend. The first few months are a lot of fun until you figure out how much you lost.

quink 15y ago
Without Netscape 6, we wouldn't have had Phoenix/Firebird/Firefox, and probably wouldn't have IE7, IE8, IE9 and KHTML/Webkit would have come about very differently and all these would have had much less competition. Netscape 6, or at least the mere fact that it existed and worked well enough and the fact that it was the first browser ever that did standards well and focused on not much else other than standards, made it the most important browser ever created. Netscape 6 was the most revolutionary browser project ever created and had the development effort behind Netscape 6 not been done, we would possibly have had a much worse very IE-only web today. Never mind that beyond all that, Netscape 4 was terrible and deserved to be thrown out.
- shadowfox 15y ago
  > Netscape 6 was the most revolutionary browser project ever created I dont disagree with the general sentiment of your comment. But as someone who attempted to use Netscape 6 at various stages of its development, I fear that statement might be stretching facts a little bit.

steve8918 15y ago

Once you start making revenues from your code, a complete rewriting is probably the worst thing you can do for your company. Sometimes it might be warranted, but customers care about solving problems, not about technology. Chances are if you wrote properly modularized code, you can rewrite modules one by one, which is perfectly legit. But just dropping everything and trying to rewrite a product from scratch is a mistake that a company usually only makes once (before they die).

raganwald 15y ago

A few people have pointed out that it’s easy to throw out your code when you (a) have tests for it, and (b) only have three months invested in it. I agree with both of those points, but want to tip my hat to a team that rewrites their code after three months. The reason some code bases can’t be rewritten after a few years is because when the code was only three months old, the team passed on the chance to rewrite it while it was still a tractable exercise.

grncdr 15y ago
Very much agree. An extra layer on the danger cake (for web apps) is if your user base grows slowly while keeping the business profitable. Suddenly (sic) you hit real capacity limits after n years, and have no idea how the "organically grown" code in question works.

kellishaver 15y ago

I'm glad they're happy with the rewrite, but honestly, this makes me feel a bit nervous about updating my Node app utilizing NowJS to the 0.7 release. Maybe it is better. Maybe it is more stable, smaller, and faster, and well-tested. But it hasn't had as much "real world" use thrown at it as the previous codebase had. I'm not saying I won't upgrade, but I'll likely wait a bit until I do and stay with what I know works right now, at least in production.

brandonwang 15y ago

Please bear in mind the counter article everyone is citing (http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html) was written 11 years ago. I'm not saying that it's wrong because it's from 11 years ago, but you really want to consider its central example. Netscape 6.0 was a complete rewrite. The article claims that this was a mistake. Now, if you would recall, one of the reasons Netscape 6.0 was completely rewritten was to use Raptor/NGLayout. Raptor/NGLayout was later renamed to Gecko. Gecko is the currently developed Firefox rendering engine, and Netscape 6.0 marked the start of the Mozilla foundation. I would harshly argue that Gecko would not have taken off nearly as well without Netscape's rewrite. But this is definitely not a story about Gecko's popularity. It's about the reason why Gecko was the decision they took at the time, and the current impact of Gecko. Besides the fact that Gecko was one of the early open-source success stories, the reason why Netscape decided to scrap everything and start from scratch was simple: Netscape 4.0 was horrid. Remember back to the days of IE vs Netscape. Netscape was significantly slower, and had no dynamic HTML among many other features. It was buggy and would crash frequently. And the development on the "continuation" of 4.0 code was simply too slow to compete, because of outdated, not modulated code, and stuff stuck in that simply "worked," and never changed to allow for future changes. Now, people attribute Netscape 6 to Netscape's death because of this radical decision. But take a look at Netscape's usage statistics: http://upload.wikimedia.org/wikipedia/en/1/16/Netscape_Navigator_usage_share.png http://upload.wikimedia.org/wikipedia/en/1/16/Netscape_Navig... . Hey, guess when Netscape 4.0 came out and IE started to dominate? 1996-1997. By 2000, when Netscape 6 was released, Netscape's usage already dwindled down to nothing. Now, you're thinking, why didn't Gecko save Netscape? It takes too long to reverse these tides. Netscape was already dead. AOL acquired Netscape in 1998, to combat IE. Then, in 2003, AOL won an antitrust suit against Microsoft, and allowed AOL to use IE royalty-free. Netscape was pretty much scrapped at that moment because the damage had been done. But wait. Mozilla released Phoenix in 2004, based on Gecko. You should now the story from there. (Clue: Phoenix -> Firefox) Disclaimer: I'm not saying that Firefox > IE or Chrome or whatever. I'm saying that the codebase Netscape 4.0 was based on was doomed to fail. Gecko still lives on today, and was started as a rewrite of Netscape. Anyway, my point is, there are times to rewrite things, and there are times to keep them the same. If you have a good, legitimate reason to rewrite, as Netscape or NowJS did, you should. If you are just the stubborn programmer that always implements his own Queue or QuickSort when libraries exist, don't.

beck5 15y ago

An attention grabbing headline but all the same I have been using now.js and its been a great tool (although a cut down on the print statements would be nice).

makecheck 15y ago

Justified or not, I think a project owes it to its users to change major version numbers when a major rewrite (much less a complete one) has occurred. As perfect as your code might be, customers deserve a hint when major changes were done under the hood. Moving from 0.6 to 0.7 screams "just a few changes, some new features", not "we threw everything out and started over". This should have been made into "1.0beta", I would think.

stephth 15y ago
There are other factors involved when deciding a version number than the code under the hood: API changes, new features, is it production ready, 'this is the now stable API that we'll be maintaining for a long time', etc. Edit: for perspective, a thoughtful proposition on how to approach software versioning: http://semver.org http://semver.org
- makecheck 15y ago
  I agree that there are many factors. I'm just saying that some changes are important enough to trump anything else; the presence of a rewrite should decide the version all by itself.

anirudh 15y ago

Its not always the right thing as there are years of issues/corner cases that have been resolved.

flocial 15y ago

Well, just because some prominent luminary says it shouldn't be done never means it's always a bad idea. A lot of the basis against rewrites are for relatively mature projects still on a high growth trajectory or large installation base. However, there are exceptions to that as well. Foursquare went from LAMP to Scala/Lift, PostgreSQL, and MongoDB with minimal complications and it's paid off handsomely to support their amazing growth. Also, the money quote: "It's managed to survive our vicious benchmarking tools and our ridiculously comprehensive test cases. " My assumption is they are using the same languages and tool sets (not porting from language X to Y). I'm curious as to how long the rewrite took though.

stretchwithme 15y ago

If you're dealing with human DNA, a complete code rewrite will likely fail. But if its just an amoeba and you have a lot of time, go for it.

shahan 15y ago

Whether their decision was right or wrong, they made a decision that big companies tend not to make. Startups should probably have a bias towards decisions like that.

jheriko 15y ago

I'd be dubious that they actually rewrote everything - having working stuff lying around that already worked, some of which was probably just fine, I'd hope it got copy-pasted into the new code...

adrianscott 15y ago

You should read the book, "In Search of Stupidity - Over 20 Years of High-Tech Marketing Disasters" Refactoring is almost always preferable to throwing out all your code, imho.

onan_barbarian 15y ago

Frequently, throwing out "all your code" is a sign you did pretty much everything wrong to begin with. Personally, the sign of a decent design is when you can wind up doing the old "Grandpa's Mattock" trick: "This is grandpa's mattock; my father replaced the handle and I replaced the blade".

nvictor 15y ago

Be ready to throw away your first version. I wish I had the right quote on hands. The K in K&R said that.