40 ms·

>What they didn’t mention is that we’re rebuilding it from scratch. In six weeks. Famous last words. http://www.joelonsoftware.com/articles/fog0000000069.html

>What they didn’t mention is that we’re rebuilding it from scratch. In six weeks. Famous last words. http://www.joelonsoftware.com/articles/fog0000000069.html http://www.joelonsoftware.com/articles/fog0000000069.html

chubot 14y ago
Wasn't rebuilding it from scratch and not being able to go back what caused Digg to fall in the first place? It's kind of rare that you see a company actually make that mistake now. But I guess Digg did.
redidas 14y ago
I'm interested and curious - anyone know of any other articles on this topic? I feel like I've come across a couple "bad" implementations of some concept (as I see it anyways), and thought the best solution would be to start over and redo it. Are there scenarios where starting from scratch is a good idea? How do you know? (As an aside, I don't think starting from scratch will revive Digg. I think its time has passed...)
- romaniv 14y ago
  That article is probably the most frequently cited piece of bad engineering advice in the world. Bad and unneeded advice, since most corporate environments are already extremely hostile to any kind of rewrites. Heck, there are companies that still run DOS "servers". Engineering black holes. They suck developer time in and bend all infrastructure around themselves.
  - lotyrin 14y ago
    Yep often all the accrued "bug fixes" accumulated in the complicated solution are "fixes" for "bugs" like "Jim didn't know that the language standard library already had a solution for this, so he made it himself, poorly" or "Pam,Bob,and Dave each had to come back and fix Jim's naive solution by coding specific logic for the corner case they each ran into". When the new hire Steve shows up and deletes the whole thing and uses the time-tested model of the wheel, he is not a villain, and anything to suggest otherwise is poor management philosophy that will drive Steves away, leaving you with a bad project, bad management and bad engineers (AKA 99% of every project ever). Even if by doing so Steve introduces bugs in the two-wrongs-make-a-right consuming code (which is simply a bug) and isn't polite enough to discover this on his own. The flexibility and resources to make systematic improvements like these which combat cruft and maintain or repair feature velocity are why QA - automated or otherwise - exists. Honestly though, I don't think the article really means to cover such a scenario. There are many times that engineers decide to replace rather than understand a system which is complex-for-a-reason, this is written specifically with that in mind. I regularly see this as I use/develop against/contribute to Drupal - a marvelously complex-for-a-reason(usually) piece of engineering that happens to be written in PHP - a language with a community that still celebrates simplicity-at-whatever-cost. "Nevermind that the theme/cache/localization/form/whathaveyou system accounts for what I need, it's more than what I need and I don't trust code more complex than I (or any single person with a single use case for that matter) could have written." He doesn't make that clear, but it's the only sense I can make of the article given his degree of experience.
pavel_lishin 14y ago
No worries, if they run out of time, there's always https://github.com/reddit/ https://github.com/reddit/
- slig 14y ago
  I remember that reddit was very hard to set up. Is it any easier nowadays?
  - dangrossman 14y ago
    You run a single script which ends with "Congratulations! reddit is now installed" Assuming everything works as planned. https://github.com/reddit/reddit/blob/master/install-reddit.sh https://github.com/reddit/reddit/blob/master/install-reddit....
    - TazeTSchnitzel 14y ago
      It never, ever does.
- emehrkay 14y ago
  Funny because the only "real" difference between reddit and digg is the fact that reddit has an unlimited amount of categories. That and people seem(ed) more interested in the reddit categories than the comparable digg ones.
  - whatgoodisaroad 14y ago
    The Digg algorithm was much easier to game than Reddit's.
    - emehrkay 14y ago
      I totally forgot about the big "gaming digg" scene. Damn its been a long time since I've used digg regularly.
pteromyscus 14y ago
One measly article does not a law constitute. There ARE counter-examples of successful systems re-built from scratch. The rewrite might have killed Netscape, for example, but without the rewrite from scratch not only would have Netscape died but there wouldn't be a Firefox or Mozilla Foundation now. (And I'd argue that it wasn't the rewrite that killed Netscape: the rewrite was necessary. What killed Netscape, and would have killed it even without the rewrite, was that the then all-mighty Microsoft decided to get into the internet game for real and build a good-enough browser. It's ironic that this good enough browser was IE6, which we know view as the worst impediment to web progress). Also, didn't Frederic Brooks say "prepare to throw one away"?
- yuhong 14y ago
  Yea, what killed Netscape was not the rewrite, but IMO the cancellation of Mariner: http://www.mozillazine.org/talkback.html?article=1708 http://www.mozillazine.org/talkback.html?article=1708 And BTW, on IE6, the lack of competition resulting from the killing of Netscape was why MS can get away with stagnating IE for 5 years in the first place.
- taylorbuley 14y ago
  Look at history: The Digg v4 rewrite was catastrophic. Not in that it didn't work (it was quite elegant engineering wise e.g. Cassandra-powered Digg buttons) but in that it took a really long time and when it was finally ready it was already behind.
  - Serplat 14y ago
    Actually, when it was first released, it simply didn't work. Very few pages actually loaded, and there were errors all over the place.
- jholman 14y ago
  Brooks has repudiated that claim, though. See for example the first question at: http://www.computerworld.com/s/article/350008/The_Grill_Fred_Brooks http://www.computerworld.com/s/article/350008/The_Grill_Fred... Also, if we're going to link Joel articles from the decade before last, let me add this one which is merely ten years old, and elaborates the ideas from the previous: http://www.joelonsoftware.com/articles/fog0000000348.html http://www.joelonsoftware.com/articles/fog0000000348.html All that said, I think there are things to be learned and gained from rewrites.
crazygringo 14y ago
Presumably they're not rebuilding the same product! So I doubt that applies at all. And a Digg-type site is not that hard to build. It's light-years away from the complexity of a web browser, for instance.
- Firehed 14y ago
  Easy to build, hard to scale (although far easier than when Digg was first built). Also getting the voting algorithm right, assuming they're going to continue with that model, takes a lot of refinement. But yeah, overall I agree. Why would they rebuild the same product? That's already failed.
- dbecker 14y ago
  Most rewrites described in that article were also intended to be substantial revisions rather than a functionally identical version with "new" code.
yuhong 14y ago
IMO, an even worse one is the MS OS/2 2.0 fiasco where MS abandoned it and the MS/IBM JDA after the SDK with a beta of it was already sent to developers. To be honest, the aforementioned JDA was not particularly good, but IBM ended up beating Chicago (Win95) by three years with OS/2 2.0, and during that gap MS used unethical tactics that was a lot worse than the JDA to attack OS/2.
RandallBrown 14y ago
The project I'm working on now is at a point where it's either spend a HUGE amount of time refactoring and fixing everything or just start over. We can't just continue adding on features with the state the code is in. The question is, which will be faster? Right now, it's written to run on an old OS, with old versions of old languages. We absolutely HAVE to update this stuff as it's just stupid to continue programming in the dark ages (no code completion, no jump to definition, printf debugging). But is it better to refactor the code and rewrite it slowly, or just scrap it, lose all of the old terrible design decisions, and move on. You ask the question "Why do you think you'd make the design decisions correctly this time around?" Well, we didn't write the first version. It was given to a vendor that totally botched the job and it's our responsibility to fix it.
- mgkimsal 14y ago
  "We absolutely HAVE to update this stuff as it's just stupid to continue programming in the dark ages" There might also be security issues. I've found that's sometimes a good rationale - if I've got code that will only work in PHP 4.1, and it's gotta work for the next 5 years, probably rewriting ('wholesale refactoring') is a much more prudent choice, even though it's "a complete rewrite". There will be no security patches for the underlying language - building on a platform with known and 'never-will-be-fixed' security holes isn't a good long-term strategy.
- MartinCron 14y ago
  My experience says that for real legacy code (deployed and actually used) it is almost always better to slice it up and re-write and deploy sections of it incrementally. Big-bang transitions with a "point of no return" are just so expensive and risky. Yes, you lose "conceptual integrity" and your UX may be inconsistent in the transitional time, but those are small prices to pay.
samstave 14y ago
What are you building from scratch. What exactly do you think you're building? I take "from scratch" to mean "we are totally rethinking everything! Look - lets not b fucking morons. The ONLY thing bought was digg.com the name which has a PR/publicity pull. You will fail - digg has sucked and will suck and even the cult of personality around kevin rose evaporated, like milk, immediately after joining Google. The fact is that the word digg and kevin rose have represented only one thing - the desire to extract fame and fortune from outdated and poor thought out ideas. I wish you only failure.
- mdpane 14y ago
  You're fucked.

chubot 14y ago

Wasn't rebuilding it from scratch and not being able to go back what caused Digg to fall in the first place? It's kind of rare that you see a company actually make that mistake now. But I guess Digg did.

redidas 14y ago

I'm interested and curious - anyone know of any other articles on this topic? I feel like I've come across a couple "bad" implementations of some concept (as I see it anyways), and thought the best solution would be to start over and redo it. Are there scenarios where starting from scratch is a good idea? How do you know? (As an aside, I don't think starting from scratch will revive Digg. I think its time has passed...)

romaniv 14y ago
That article is probably the most frequently cited piece of bad engineering advice in the world. Bad and unneeded advice, since most corporate environments are already extremely hostile to any kind of rewrites. Heck, there are companies that still run DOS "servers". Engineering black holes. They suck developer time in and bend all infrastructure around themselves.
- lotyrin 14y ago
  Yep often all the accrued "bug fixes" accumulated in the complicated solution are "fixes" for "bugs" like "Jim didn't know that the language standard library already had a solution for this, so he made it himself, poorly" or "Pam,Bob,and Dave each had to come back and fix Jim's naive solution by coding specific logic for the corner case they each ran into". When the new hire Steve shows up and deletes the whole thing and uses the time-tested model of the wheel, he is not a villain, and anything to suggest otherwise is poor management philosophy that will drive Steves away, leaving you with a bad project, bad management and bad engineers (AKA 99% of every project ever). Even if by doing so Steve introduces bugs in the two-wrongs-make-a-right consuming code (which is simply a bug) and isn't polite enough to discover this on his own. The flexibility and resources to make systematic improvements like these which combat cruft and maintain or repair feature velocity are why QA - automated or otherwise - exists. Honestly though, I don't think the article really means to cover such a scenario. There are many times that engineers decide to replace rather than understand a system which is complex-for-a-reason, this is written specifically with that in mind. I regularly see this as I use/develop against/contribute to Drupal - a marvelously complex-for-a-reason(usually) piece of engineering that happens to be written in PHP - a language with a community that still celebrates simplicity-at-whatever-cost. "Nevermind that the theme/cache/localization/form/whathaveyou system accounts for what I need, it's more than what I need and I don't trust code more complex than I (or any single person with a single use case for that matter) could have written." He doesn't make that clear, but it's the only sense I can make of the article given his degree of experience.

pavel_lishin 14y ago

No worries, if they run out of time, there's always https://github.com/reddit/ https://github.com/reddit/

slig 14y ago
I remember that reddit was very hard to set up. Is it any easier nowadays?
- dangrossman 14y ago
  You run a single script which ends with "Congratulations! reddit is now installed" Assuming everything works as planned. https://github.com/reddit/reddit/blob/master/install-reddit.sh https://github.com/reddit/reddit/blob/master/install-reddit....
  - TazeTSchnitzel 14y ago
    It never, ever does.
emehrkay 14y ago
Funny because the only "real" difference between reddit and digg is the fact that reddit has an unlimited amount of categories. That and people seem(ed) more interested in the reddit categories than the comparable digg ones.
- whatgoodisaroad 14y ago
  The Digg algorithm was much easier to game than Reddit's.
  - emehrkay 14y ago
    I totally forgot about the big "gaming digg" scene. Damn its been a long time since I've used digg regularly.

pteromyscus 14y ago

One measly article does not a law constitute. There ARE counter-examples of successful systems re-built from scratch. The rewrite might have killed Netscape, for example, but without the rewrite from scratch not only would have Netscape died but there wouldn't be a Firefox or Mozilla Foundation now. (And I'd argue that it wasn't the rewrite that killed Netscape: the rewrite was necessary. What killed Netscape, and would have killed it even without the rewrite, was that the then all-mighty Microsoft decided to get into the internet game for real and build a good-enough browser. It's ironic that this good enough browser was IE6, which we know view as the worst impediment to web progress). Also, didn't Frederic Brooks say "prepare to throw one away"?

yuhong 14y ago
Yea, what killed Netscape was not the rewrite, but IMO the cancellation of Mariner: http://www.mozillazine.org/talkback.html?article=1708 http://www.mozillazine.org/talkback.html?article=1708 And BTW, on IE6, the lack of competition resulting from the killing of Netscape was why MS can get away with stagnating IE for 5 years in the first place.
taylorbuley 14y ago
Look at history: The Digg v4 rewrite was catastrophic. Not in that it didn't work (it was quite elegant engineering wise e.g. Cassandra-powered Digg buttons) but in that it took a really long time and when it was finally ready it was already behind.
- Serplat 14y ago
  Actually, when it was first released, it simply didn't work. Very few pages actually loaded, and there were errors all over the place.
jholman 14y ago
Brooks has repudiated that claim, though. See for example the first question at: http://www.computerworld.com/s/article/350008/The_Grill_Fred_Brooks http://www.computerworld.com/s/article/350008/The_Grill_Fred... Also, if we're going to link Joel articles from the decade before last, let me add this one which is merely ten years old, and elaborates the ideas from the previous: http://www.joelonsoftware.com/articles/fog0000000348.html http://www.joelonsoftware.com/articles/fog0000000348.html All that said, I think there are things to be learned and gained from rewrites.

crazygringo 14y ago

Presumably they're not rebuilding the same product! So I doubt that applies at all. And a Digg-type site is not that hard to build. It's light-years away from the complexity of a web browser, for instance.

Firehed 14y ago
Easy to build, hard to scale (although far easier than when Digg was first built). Also getting the voting algorithm right, assuming they're going to continue with that model, takes a lot of refinement. But yeah, overall I agree. Why would they rebuild the same product? That's already failed.
dbecker 14y ago
Most rewrites described in that article were also intended to be substantial revisions rather than a functionally identical version with "new" code.

yuhong 14y ago

IMO, an even worse one is the MS OS/2 2.0 fiasco where MS abandoned it and the MS/IBM JDA after the SDK with a beta of it was already sent to developers. To be honest, the aforementioned JDA was not particularly good, but IBM ended up beating Chicago (Win95) by three years with OS/2 2.0, and during that gap MS used unethical tactics that was a lot worse than the JDA to attack OS/2.

RandallBrown 14y ago

The project I'm working on now is at a point where it's either spend a HUGE amount of time refactoring and fixing everything or just start over. We can't just continue adding on features with the state the code is in. The question is, which will be faster? Right now, it's written to run on an old OS, with old versions of old languages. We absolutely HAVE to update this stuff as it's just stupid to continue programming in the dark ages (no code completion, no jump to definition, printf debugging). But is it better to refactor the code and rewrite it slowly, or just scrap it, lose all of the old terrible design decisions, and move on. You ask the question "Why do you think you'd make the design decisions correctly this time around?" Well, we didn't write the first version. It was given to a vendor that totally botched the job and it's our responsibility to fix it.

mgkimsal 14y ago
"We absolutely HAVE to update this stuff as it's just stupid to continue programming in the dark ages" There might also be security issues. I've found that's sometimes a good rationale - if I've got code that will only work in PHP 4.1, and it's gotta work for the next 5 years, probably rewriting ('wholesale refactoring') is a much more prudent choice, even though it's "a complete rewrite". There will be no security patches for the underlying language - building on a platform with known and 'never-will-be-fixed' security holes isn't a good long-term strategy.
MartinCron 14y ago
My experience says that for real legacy code (deployed and actually used) it is almost always better to slice it up and re-write and deploy sections of it incrementally. Big-bang transitions with a "point of no return" are just so expensive and risky. Yes, you lose "conceptual integrity" and your UX may be inconsistent in the transitional time, but those are small prices to pay.

samstave 14y ago

What are you building from scratch. What exactly do you think you're building? I take "from scratch" to mean "we are totally rethinking everything! Look - lets not b fucking morons. The ONLY thing bought was digg.com the name which has a PR/publicity pull. You will fail - digg has sucked and will suck and even the cult of personality around kevin rose evaporated, like milk, immediately after joining Google. The fact is that the word digg and kevin rose have represented only one thing - the desire to extract fame and fortune from outdated and poor thought out ideas. I wish you only failure.

mdpane 14y ago
You're fucked.