6 ms·

Things You Should Never Do, Part I

50 points by Jakob 17y ago

camperman 17y ago
This article has not dated well at all. Compare IE's security track record with, er, just about any other browser and it's clear that sometimes throwing away a teetering house of cards and starting again is absolutely the best thing to do.
- jmtame 17y ago
  didn't they do that on one of the mac os versions too? and it turned out to be one of the best choices jobs claims he made?
  - rms 17y ago
    Yes, OS X, but they started with FreeBSD so it doesn't quite count.
    - boundlessdreamz 17y ago
      It does count, they may have started with FreeBSD but they also had to write/rewrite a ton of stuff and throw away APIs and introduce new ones. I think the FreeBSD code is only a tiny (but critical) part of OSX
      - ensignavenger 17y ago
        Actually, there is NO FreeBSD code in OS X- see this presentation- http://events.ccc.de/congress/2007/Fahrplan/events/2303.en.html http://events.ccc.de/congress/2007/Fahrplan/events/2303.en.h... (Someone posted it on HN some time ago).
        j_baker 17y ago
        I think you mean to say that there is no FreeBSD code in the OS X kernel.
        ensignavenger 17y ago
        Yeah, that is what I meant. It certainly isn't "based on" FreeBSD.
        ensignavenger 17y ago
        Yeah, that is what I meant. It certainly isn't "based on" FreeBSD.
      - bodhi 17y ago
        And the rest is from NeXT? (I kid, I kid.)
      - encoderer 17y ago
        The part you're overlooking is that NeXT was as attractive to Apple as it was because they had a series of high-profile failures to develop a replacement OS in house. In Apple's case the re-write idea turned out horribly and the only reason they made it thru is because a former founder had created a startup years earlier and had a working OS that Apple could buy and use. Apple is hardly a poster child for re-writing software.
        rbanffy 17y ago
        At least the look and feel they developed for Copland were re-used in MacOS 8 and 9... It looked cool, in the late 90s.
  - codesink 17y ago
    The kernel code comes from xnu and freebsd, the UI stuff and the development tools comes stright from the NeXT that's about 20 years old. Of course those are just the starting points, from that a lot has been reworked/improved and a lot has been added.
thristian 17y ago
It's interesting to look back on this classic JoS article, with the perspective that Mozilla's rewrite-from-scratch basically kept the organisation around long enough for Firefox to come along, and look where that went. If Netscape hadn't made the decision to rewrite, they'd have released a browser even less well-suited for the then-modern Internet than Netscape 4 was when it came out, they'd have sunk even quicker, and there would have been nothing worth salvaging from the corpse - no Mozilla Foundation, no Suite, and ultimately no Firefox.
- mattmanser 17y ago
  Surely this is only really valid point if Friefox saved Netscape? Is the most pressing concern of a owner/shareholder/employee that a company starts a successful open source project? No, it's food on the table! It didn't save most people's job. Joel's point is still valid, commercially it was suicide. 3D Realm's constant rewriting of Duke Nukem Forever bottom up is another topical reminder of just how stupid it is. Another dead company.
  - DannoHung 17y ago
    I think the moral is "RELEASE DAMNIT", not "don't rewrite". If you can rewrite and still release, rewrite away.
- boundlessdreamz 17y ago
  Yeah, If you are being bogged down by legacy code and increasingly falling behind competitors due to slow innovation, it makes sense to do a rewrite. Mozilla had nothing to lose by a rewrite and everything to gain. In the short term they suffered immensely falling behind even more but in the long term it helped them emerge stronger. It is the same with Classic Mac -> OSX. The former was crumbling under its own weight but OSX enabled Apple to out innovate others. The key point is that a rewrite should always produce something better and leaner. Two cases where it didn't happen are * In case PG's viaweb -> Yahoo store. http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02367.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m... * When Sony acquired Naughty Dog. http://bc.tech.coop/blog/060118.html http://bc.tech.coop/blog/060118.html
swombat 17y ago
It's a delicate point, because on this one Joel is both right and wrong, depending on the circumstances. He's absolutely right that the "Big Rewrite" is a very dangerous proposition that should be assessed very carefully, but sometimes, it is the right choice. I'll agree that in 95% of the cases it's not the right choice, though. We programmers do love us a good rewrite, even when it's bad for us. Incidentally, the Mozilla rewrite was probably in the 5% where it did make sense.
- lallysingh 17y ago
  I think a fair interpretation is if you have both conditions: 1. Is the whole code base a maintenance nightmare? 2. Do we have to change all of it right now? Which occurs, rarely. Most of the time a mechanical transform (e.g. Emacs macro) helps with the annoyances and standards. The rest, a deep refactoring is needed. Frankly, dumping the source and starting from scratch sounds a little like running away from your problems instead of attacking them head-on.
ashot 17y ago
chrome
- c00p3r 17y ago
  This is Webkit + V8 + minimalism + usability (and other really good ideas like comics promotions), so, only V8 is what was written from scratch. This is very good example of really smart approach. Another one is the reuse of Java/Eclipse ecosystem for Android development, same as Google App Engine Java. In both cases they rewrote VMs.
mpk 17y ago
Given the state of the code when it was released, I can't really say I blame the developers for thinking 'screw this'. Check out the comments they had to delete before releasing the code : http://www.jwz.org/doc/censorzilla.html http://www.jwz.org/doc/censorzilla.html .
- DLWormwood 17y ago
  I find it a little disturbing that "hack" was one of the censor words, especially since it has a very specific meaning when appearing in source code (and many commenting tools even do special processing when it sees this word.)
rbanffy 17y ago
Funny he implies the bundling of IE in every copy of Windows and the threats against OEMs who thought about bundling any other browser had nothing to do with the failure of Netscape. It's true Netscape 4 lasted very long and was tough to improve, but I think that blaming Netscape for not having resources comparable to Microsoft is not entirely fair. A rewrite is a risky proposition and should not be taken lightly. If Netscape did something wrong it was not to do it right after 4's launch.
- discojesus 17y ago
  Funny he implies the bundling of IE in every copy of Windows and the threats against OEMs who thought about bundling any other browser had nothing to do with the failure of Netscape. He doesn't just imply it - he says it explicitly in another article of his [http://www.joelonsoftware.com/articles/fog0000000074.html http://www.joelonsoftware.com/articles/fog0000000074.html]: "When Microsoft released Internet Explorer 3.0, fast on the heels of IE 2.0, it was shocking just how good a job they had done. Not only did they replicate every feature in Netscape's browser, but they added some more features too, and did it all with an architecture that was robust and strategic. While it is true that Microsoft used its operating system to help push its browser, it is also true that they just wouldn't have gotten away with this if their browser wasn't great. (Case in point: even though Windows out of the box can play MP3 files, everyone I know uses WinAmp, not the Windows Media Player, to listen to them. Even though MSN is on the desktop, everybody uses AOL. Back when the browser integrated with Windows was crap, Netscape had 80% market share. So please stop fretting about the power of bundling.)" And moreover, he's correct.
  - rbanffy 17y ago
    Everybody _he_ knew used WinAmp (in a time WMP was completely either useless or non-existent). About 40% of the people I know and work with would not touch Windows with a pole. Those do not make a significant cross-section of the market. Just like most people just lives with the OS their computer came with, most people just live with the browser that is installed by default either by the manufacturer or by their corporate overlords. IE3 was the first "good enough" browser that came from Microsoft and, from 98 on, IE came bundled. For those who do not live in and for the web, "whatever comes with the computer" is what gets used. That was the last nail in Netscape's coffin.
c00p3r 17y ago
Honestly, I didn't understand the reason of re-posting that old stuff. This man got his niche as a popular blogger and he is really good in that sort of blah-blah-blah re-telling-the-obvious-things posts. But why here?
rbanffy 17y ago
And, BTW, "this is the kind of thing you solve in five minutes with a macro in Emacs" looks almost like Joel Spolsky knew the HN crowd would eventually come...
jasongullickson 17y ago
This argument (don't re-write) sounds great to laymen and managers because they see "the code" as the sole artifact of the development effort. The flaw here (known to almost any developer) is that the code itself, the physical files and such represents the work of developing an application as completely as a photograph of a boxing match represents boxing itself. Evidence of this can be seen in the many examples of companies "buying out" an application by taking only the source and attempting to run with it. The results are rarely, if ever, spectacular. Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program. Why? Because by the end of the project you know more than you did at the beginning, and when you re-write the code from scratch you can leverage this knowledge on all of the code, not just the code you wrote after you learned these lessons. In this way it is impossible to re-write something (unless you are starting with new developers as well), just like if you asked Stephen King to re-write (as in, re-type) The Shining...
- jderick 17y ago
  I agree. So essentially the "rust" in a codebase is the differential between what your developers know about the code and what knowledge is embedded in the code. Since it is much harder to read code than write it (at least, for "awful" codebases), once code has rusted enough it is best to just throw it away. On the flip side, if you are able to keep your developers up to date on the codebase, you will save yourself a lot of trouble.
- tapostrophemo 17y ago
  "Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program." Well, not always. What about the edge cases the developer has long since forgotten? Unless you've also got a good test suite that covers those cases, you're exposing yourself to the risk of missing those edge cases in a sans-source re-write.
  - jasongullickson 17y ago
    You're absolutely correct. However I would argue that, if you are in a situation where the developer (developers, development team, etc.) is no longer is aware of these edge cases, you have bigger problems than a shipping delay due to a re-write.
joshu 17y ago
When you see advice containing words like "never" and "always" and "just" you need to take that advice with a HUGE grain of salt. Joel's point stands - rewriting for the sake of rewriting is frequently a mistake. I know it was a huge mistake in the case of Delicious 2, for example. But that doesn't mean that starting from scratch is ALWAYS a mistake, etc, etc. As a programmer and as a manager of a product, I think you basically need to try a bunch of things and get burned a bunch of times to properly learn when and where to do things.
j_baker 17y ago
Alright, I've been meaning to write up a blog post detailing my thoughts on this subject. This post prompted me to. Here it is, enjoy: http://jasonmbaker.wordpress.com/2009/05/14/programming-and-safe-theater-or-things-you-have-to-do-but-shouldnt-if-you-can-avoid-doing-them-at-any-cost/ http://jasonmbaker.wordpress.com/2009/05/14/programming-and-...
jpcx01 17y ago
I agree. If you're taking over an old crappy Rails project of reasonable complexity, think about using Pat Maddox's excellent tips on working with legacy databases. http://www.patmaddox.com/blog/railsconf_2009_legacy_rails http://www.patmaddox.com/blog/railsconf_2009_legacy_rails It's useful to get the app under a comprehensive test acceptance test suite. Then you can rewrite and feel comfortable everything is still working.
vicaya 17y ago
Reuse is overrated and rewrite is underrated. It's true that typical first rewrite suffers from [second/sophomore system syndrome](http://en.wikipedia.org/wiki/Second-system_effect http://en.wikipedia.org/wiki/Second-system_effect) The only way to overcome that is to do more rewrites :)

50 points by Jakob 17y ago

This article has not dated well at all. Compare IE's security track record with, er, just about any other browser and it's clear that sometimes throwing away a teetering house of cards and starting again is absolutely the best thing to do.

jmtame 17y ago
didn't they do that on one of the mac os versions too? and it turned out to be one of the best choices jobs claims he made?
- rms 17y ago
  Yes, OS X, but they started with FreeBSD so it doesn't quite count.
  - boundlessdreamz 17y ago
    It does count, they may have started with FreeBSD but they also had to write/rewrite a ton of stuff and throw away APIs and introduce new ones. I think the FreeBSD code is only a tiny (but critical) part of OSX
    - ensignavenger 17y ago
      Actually, there is NO FreeBSD code in OS X- see this presentation- http://events.ccc.de/congress/2007/Fahrplan/events/2303.en.html http://events.ccc.de/congress/2007/Fahrplan/events/2303.en.h... (Someone posted it on HN some time ago).
      - j_baker 17y ago
        I think you mean to say that there is no FreeBSD code in the OS X kernel.
        ensignavenger 17y ago
        Yeah, that is what I meant. It certainly isn't "based on" FreeBSD.
        ensignavenger 17y ago
        Yeah, that is what I meant. It certainly isn't "based on" FreeBSD.
    - bodhi 17y ago
      And the rest is from NeXT? (I kid, I kid.)
    - encoderer 17y ago
      The part you're overlooking is that NeXT was as attractive to Apple as it was because they had a series of high-profile failures to develop a replacement OS in house. In Apple's case the re-write idea turned out horribly and the only reason they made it thru is because a former founder had created a startup years earlier and had a working OS that Apple could buy and use. Apple is hardly a poster child for re-writing software.
      - rbanffy 17y ago
        At least the look and feel they developed for Copland were re-used in MacOS 8 and 9... It looked cool, in the late 90s.
- codesink 17y ago
  The kernel code comes from xnu and freebsd, the UI stuff and the development tools comes stright from the NeXT that's about 20 years old. Of course those are just the starting points, from that a lot has been reworked/improved and a lot has been added.

thristian 17y ago

It's interesting to look back on this classic JoS article, with the perspective that Mozilla's rewrite-from-scratch basically kept the organisation around long enough for Firefox to come along, and look where that went. If Netscape hadn't made the decision to rewrite, they'd have released a browser even less well-suited for the then-modern Internet than Netscape 4 was when it came out, they'd have sunk even quicker, and there would have been nothing worth salvaging from the corpse - no Mozilla Foundation, no Suite, and ultimately no Firefox.

mattmanser 17y ago
Surely this is only really valid point if Friefox saved Netscape? Is the most pressing concern of a owner/shareholder/employee that a company starts a successful open source project? No, it's food on the table! It didn't save most people's job. Joel's point is still valid, commercially it was suicide. 3D Realm's constant rewriting of Duke Nukem Forever bottom up is another topical reminder of just how stupid it is. Another dead company.
- DannoHung 17y ago
  I think the moral is "RELEASE DAMNIT", not "don't rewrite". If you can rewrite and still release, rewrite away.
boundlessdreamz 17y ago
Yeah, If you are being bogged down by legacy code and increasingly falling behind competitors due to slow innovation, it makes sense to do a rewrite. Mozilla had nothing to lose by a rewrite and everything to gain. In the short term they suffered immensely falling behind even more but in the long term it helped them emerge stronger. It is the same with Classic Mac -> OSX. The former was crumbling under its own weight but OSX enabled Apple to out innovate others. The key point is that a rewrite should always produce something better and leaner. Two cases where it didn't happen are * In case PG's viaweb -> Yahoo store. http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg02367.html http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/m... * When Sony acquired Naughty Dog. http://bc.tech.coop/blog/060118.html http://bc.tech.coop/blog/060118.html

swombat 17y ago

It's a delicate point, because on this one Joel is both right and wrong, depending on the circumstances. He's absolutely right that the "Big Rewrite" is a very dangerous proposition that should be assessed very carefully, but sometimes, it is the right choice. I'll agree that in 95% of the cases it's not the right choice, though. We programmers do love us a good rewrite, even when it's bad for us. Incidentally, the Mozilla rewrite was probably in the 5% where it did make sense.

lallysingh 17y ago
I think a fair interpretation is if you have both conditions: 1. Is the whole code base a maintenance nightmare? 2. Do we have to change all of it right now? Which occurs, rarely. Most of the time a mechanical transform (e.g. Emacs macro) helps with the annoyances and standards. The rest, a deep refactoring is needed. Frankly, dumping the source and starting from scratch sounds a little like running away from your problems instead of attacking them head-on.

ashot 17y ago

chrome

c00p3r 17y ago
This is Webkit + V8 + minimalism + usability (and other really good ideas like comics promotions), so, only V8 is what was written from scratch. This is very good example of really smart approach. Another one is the reuse of Java/Eclipse ecosystem for Android development, same as Google App Engine Java. In both cases they rewrote VMs.

mpk 17y ago

Given the state of the code when it was released, I can't really say I blame the developers for thinking 'screw this'. Check out the comments they had to delete before releasing the code : http://www.jwz.org/doc/censorzilla.html http://www.jwz.org/doc/censorzilla.html .

DLWormwood 17y ago
I find it a little disturbing that "hack" was one of the censor words, especially since it has a very specific meaning when appearing in source code (and many commenting tools even do special processing when it sees this word.)

rbanffy 17y ago

Funny he implies the bundling of IE in every copy of Windows and the threats against OEMs who thought about bundling any other browser had nothing to do with the failure of Netscape. It's true Netscape 4 lasted very long and was tough to improve, but I think that blaming Netscape for not having resources comparable to Microsoft is not entirely fair. A rewrite is a risky proposition and should not be taken lightly. If Netscape did something wrong it was not to do it right after 4's launch.

discojesus 17y ago
Funny he implies the bundling of IE in every copy of Windows and the threats against OEMs who thought about bundling any other browser had nothing to do with the failure of Netscape. He doesn't just imply it - he says it explicitly in another article of his [http://www.joelonsoftware.com/articles/fog0000000074.html http://www.joelonsoftware.com/articles/fog0000000074.html]: "When Microsoft released Internet Explorer 3.0, fast on the heels of IE 2.0, it was shocking just how good a job they had done. Not only did they replicate every feature in Netscape's browser, but they added some more features too, and did it all with an architecture that was robust and strategic. While it is true that Microsoft used its operating system to help push its browser, it is also true that they just wouldn't have gotten away with this if their browser wasn't great. (Case in point: even though Windows out of the box can play MP3 files, everyone I know uses WinAmp, not the Windows Media Player, to listen to them. Even though MSN is on the desktop, everybody uses AOL. Back when the browser integrated with Windows was crap, Netscape had 80% market share. So please stop fretting about the power of bundling.)" And moreover, he's correct.
- rbanffy 17y ago
  Everybody _he_ knew used WinAmp (in a time WMP was completely either useless or non-existent). About 40% of the people I know and work with would not touch Windows with a pole. Those do not make a significant cross-section of the market. Just like most people just lives with the OS their computer came with, most people just live with the browser that is installed by default either by the manufacturer or by their corporate overlords. IE3 was the first "good enough" browser that came from Microsoft and, from 98 on, IE came bundled. For those who do not live in and for the web, "whatever comes with the computer" is what gets used. That was the last nail in Netscape's coffin.

c00p3r 17y ago

Honestly, I didn't understand the reason of re-posting that old stuff. This man got his niche as a popular blogger and he is really good in that sort of blah-blah-blah re-telling-the-obvious-things posts. But why here?

rbanffy 17y ago

And, BTW, "this is the kind of thing you solve in five minutes with a macro in Emacs" looks almost like Joel Spolsky knew the HN crowd would eventually come...

jasongullickson 17y ago

This argument (don't re-write) sounds great to laymen and managers because they see "the code" as the sole artifact of the development effort. The flaw here (known to almost any developer) is that the code itself, the physical files and such represents the work of developing an application as completely as a photograph of a boxing match represents boxing itself. Evidence of this can be seen in the many examples of companies "buying out" an application by taking only the source and attempting to run with it. The results are rarely, if ever, spectacular. Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program. Why? Because by the end of the project you know more than you did at the beginning, and when you re-write the code from scratch you can leverage this knowledge on all of the code, not just the code you wrote after you learned these lessons. In this way it is impossible to re-write something (unless you are starting with new developers as well), just like if you asked Stephen King to re-write (as in, re-type) The Shining...

jderick 17y ago
I agree. So essentially the "rust" in a codebase is the differential between what your developers know about the code and what knowledge is embedded in the code. Since it is much harder to read code than write it (at least, for "awful" codebases), once code has rusted enough it is best to just throw it away. On the flip side, if you are able to keep your developers up to date on the codebase, you will save yourself a lot of trouble.
tapostrophemo 17y ago
"Most of the application is in the minds of the developers. Take away his source and ask a developer to re-write an application and you are guaranteed to get a better program." Well, not always. What about the edge cases the developer has long since forgotten? Unless you've also got a good test suite that covers those cases, you're exposing yourself to the risk of missing those edge cases in a sans-source re-write.
- jasongullickson 17y ago
  You're absolutely correct. However I would argue that, if you are in a situation where the developer (developers, development team, etc.) is no longer is aware of these edge cases, you have bigger problems than a shipping delay due to a re-write.

joshu 17y ago

When you see advice containing words like "never" and "always" and "just" you need to take that advice with a HUGE grain of salt. Joel's point stands - rewriting for the sake of rewriting is frequently a mistake. I know it was a huge mistake in the case of Delicious 2, for example. But that doesn't mean that starting from scratch is ALWAYS a mistake, etc, etc. As a programmer and as a manager of a product, I think you basically need to try a bunch of things and get burned a bunch of times to properly learn when and where to do things.

j_baker 17y ago

Alright, I've been meaning to write up a blog post detailing my thoughts on this subject. This post prompted me to. Here it is, enjoy: http://jasonmbaker.wordpress.com/2009/05/14/programming-and-safe-theater-or-things-you-have-to-do-but-shouldnt-if-you-can-avoid-doing-them-at-any-cost/ http://jasonmbaker.wordpress.com/2009/05/14/programming-and-...

jpcx01 17y ago

I agree. If you're taking over an old crappy Rails project of reasonable complexity, think about using Pat Maddox's excellent tips on working with legacy databases. http://www.patmaddox.com/blog/railsconf_2009_legacy_rails http://www.patmaddox.com/blog/railsconf_2009_legacy_rails It's useful to get the app under a comprehensive test acceptance test suite. Then you can rewrite and feel comfortable everything is still working.

vicaya 17y ago

Reuse is overrated and rewrite is underrated. It's true that typical first rewrite suffers from [second/sophomore system syndrome](http://en.wikipedia.org/wiki/Second-system_effect http://en.wikipedia.org/wiki/Second-system_effect) The only way to overcome that is to do more rewrites :)