Things You Should Never Do, Part I | Hacker News Reader

Things You Should Never Do, Part I

joelonsoftware.com

50 pointsJakob40 comments

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

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.

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

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.

But one of Joel's points is that, by the time you get around to rewriting something, you usually aren't dealing with the same programmers.

If this isn't the case, and you have the same core team available, then I agree, it is sometimes better to rewrite. But these days, refactoring techniques and testing methodologies are much more concretely defined and practice, so it still may be possible to essentially "rewrite" the code without having an X year shipping delay.

Agreed, this is why small, dedicated teams (for example, those with skin in the game in regard to the company's success) is the best insurance against this unfortunate scenario (loosing the original developers).

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.

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.

I think the moral is "RELEASE DAMNIT", not "don't rewrite".

If you can rewrite and still release, rewrite away.

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

* When Sony acquired Naughty Dog. http://bc.tech.coop/blog/060118.html

The "Jak and Daxter" postmortem lists Naughty Dog's use of Lisp as the number five thing under "what went right" and the number one thing under "what went wrong"... (http://www.gamasutra.com/view/feature/2985/postmortem_naught...)

The rewrite wasn't a clear loss -- especially if, as the postmortem suggests, there was exactly one person who was capable of modifying the old codebase. (Likely this is the same person being quoted in Bill Clementson's article, which suggests some amount of ownership bias. Come to think of it, the same could be said of the ViaWeb case...)

True..but since Naughty Dog's features were due to it being written in Lisp, wouldn't it have been better if Sony trained people in Lisp ?

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.

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?

Yes, OS X, but they started with FreeBSD so it doesn't quite count.

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

And the rest is from NeXT?

(I kid, I kid.)

Actually, there is NO FreeBSD code in OS X- see this presentation- http://events.ccc.de/congress/2007/Fahrplan/events/2303.en.h... (Someone posted it on HN some time ago).

I think you mean to say that there is no FreeBSD code in the OS X kernel.

Yeah, that is what I meant. It certainly isn't "based on" FreeBSD.

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.

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.

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.

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.

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.

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.

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 .

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

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.

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]:

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

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.

For those who do not live in and for the web, "whatever comes with the computer" is what gets used.

MSN wasn't anywhere near as popular as AOL. But why not? After all, it satisifed your criterion, because it "came with the computer."

Also, MSN chat is nowhere near as popular as AOL Instant Messenger

Microsoft Money (bundled with my computer) isn't as popular as Quicken.

Microsoft Works isn't as popular as Microsoft Office.

and on and on and on...

The only way bundling matters is if the program being bundled falls into the category of "Good Enough" for the user in question. IE satisfied this criterion; MSN did not.

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

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.

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

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)

The only way to overcome that is to do more rewrites :)

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

chrome

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.

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?

Reply on news.ycombinator.com