Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

blog.nowjs.com

Post reply on HN
Print view View original

31–40 of 66 posts

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

#31

Post by Cushman »

neilk wrote: post #19
josephcooney wrote: post #11

Earlier quoted context omitted.

+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.

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 fro…

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.

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

#33

Post by flocial »

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.

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

#35

Post by tedkalaw »

dasher wrote: post #28
brandonwang wrote: post #25

Please bear in mind the counter article everyone is citing ( 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 rew…

Holding onto code just because is a foolish notion. Sometimes approaching things with a fresh perspective is what's best - it allows you to apply what you've learned so far and actually improve not just one section of code, but the whole kit & caboodle. This is one of the reasons you should write tests as you develop - it ensures you have a consistent baseline you can apply. As a developer you are constantly learning…

I think that this applies to the technology you're using as well.

I've been thinking about this because I'm writing an application in Rails and realized relatively recently that it would be better suited as a Node application. My motivation for using Rails was that it was what I knew the best. Luckily for me, the most time-consuming part was the front-end, not the Rails part, so I'm hoping my switch to Node will be relatively painless.

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

#36

Post by stephth »

makecheck wrote: post #27

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…

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

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

#37

Post by raldi »

badclient wrote: post #29
raldi wrote: post #7

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 implies) and it's also…

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.

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.

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

#39

Post by damoncali »

badclient wrote: post #29
raldi wrote: post #7

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 implies) and it's also…

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.

I think it's a good one. Think of commercial real estate. You have an old shopping center that is cash flowing. Its maintenance costs are high, and the rent is low. Once upon a time it made sense for the market and the style was perfect. Now it's out of date and the units are not exactly what people are looking for.

You could tear it down and build a fancy new one that would cash flow even more with higher rents and lower costs. It's exactly what the market needs today. Green energy, nice, open spaces, new paint. Do you break out the bulldozers?

It depends, of course.

Post reply on HN