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

51–60 of 66 posts

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

#51

Post by shadowfox »

quink wrote: post #45
d2 wrote: post #18

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. Evolvi…

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…

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

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

#52

Post by andrewflnr »

ctide wrote: post #47
pyre wrote: post #23

Earlier quoted context omitted.

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!"

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.

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.

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

#53

Post by badclient »

raldi wrote: post #46
badclient wrote: post #43

Earlier quoted context omitted.

Absolutely, as someone who grew up in a city like Mumbai, I know much about shanty towns and from my knowledge of them, they are far from ideal. ie. They are not know for a strong foundation, cleanliness, longevity etc. They are constantly hacked and patched by its residents to ensure basics like protection from rain, electricity and basics like a toilet.

And that's how New York and Rome and Shanghai grew into world cities. They didn't pave them over and start from scratch. They grew out of shantytowns.

But wait, we were talking about buildings, not cities. A city is made up of many buildings. And buildings are torn down across cities on a daily basis.

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

#54

Post by MartinCron »

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.

My local zoo actually built a full-size prototype of their new penguin exhibit ahead of building the exhibit itself. Once people could actually walk around in the space, some improvements were obvious.

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

#55

Post by Cushman »

praeclarum wrote: post #14
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…

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.

Or maybe closer to "We're putting this model building in the closet since we built the real one."

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

#56

Post by tkahn6 »

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.

Here's an example:

http://www.vt.edu/about/buildings/surge_space_building.html

"The building provides space to temporarily house academic or administrative units that are displaced because of renovations to their home buildings. The facility was designed using a pre-engineered steel frame with its exterior clad in metal panels and precast concrete-like panel accents. The building is designed to be disassembled and recycled in 10 or 15 years.

One floor; 45,000 square feet. Find a public access defibrillator in the hall intersect."

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

#57

Post by rickmb »

ctide wrote: post #15

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.

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.

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

#58

Post by ctide »

rickmb wrote: post #57
ctide wrote: post #15

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.

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.

Very important clarification, you are quite correct.

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

#59

Post by kayoone »

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.

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

#60

Post by makecheck »

stephth wrote: post #36
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

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.
Post reply on HN