[obiterdictum]

Note the article is from 2000. Joel mostly talks about big and mature desktop software (big as in Microsoft Excel). Average startup's code is small, narrowly focused, has a (relatively) short lifespan, so it can be rewritten from scratch by 1 or 2 people.

If you've ever worked with legacy systems older than 10 years, you'd notice that they become a victim of their own "success". You can't throw away features added over years, because a lot of users depend on it, and if you tried to rewrite it, you'd have to rewrite bug-to-bug.

I worked on such systems, and I did try rewriting, and gave up because of sheer volume of work and the knowledge of institutional lore that was required to do it. On the other hand I'm currently embarking on our startup's "rewrite" and things are much much easier, because the feature set is small and I can freely throw away stuff that didn't work.

See also, http://en.wikipedia.org/wiki/Gall's_law

[smacktoward]

> Average startup's code is small, narrowly focused, has a (relatively) short lifespan, so it can be rewritten from scratch by 1 or 2 people.

But the reason those startups can be narrowly focused is because they can leverage huge volumes of working code written by others. In that sense, Joel's advice still holds, if you think of "rewrite" less as "throwing out your own code and starting over" as "throwing out memcache and writing your own caching layer/throwing out Postgres and writing your own database/etc." Which is a temptation that lots of startups fall victim to, rarely with a happy ending.

[RogerL]

My bad, I brought up 'start up', but that was not the point of my comment. Big as in Excel? Well, we have OpenOffice, Google Docs, and so on. They were written from scratch with the aim to compete with Excel/Office.

As for the victim of their own success, I addressed that, arguing that it is often inertia and silliness, as we accept different feature sets when we switch our tools out.

The reality is, we rewrite all the time. I used to develop in Borland and OWL. I moved apps into MFC and Visual Studio. Now stuff is being moved into Qt. People have switched from native to cloud, and so on. We endlessly move to new platforms, new software, and so on. In all those cases we accept that the feature set will be different, yet for some reason we don't accept it when we are rewriting an app. I'm not dismissing the cost - if you need to generate a TSP report, and I don't offer that feature, then you are pulling out Python or something to hack it together yourself, and that has to be counted as part of the cost of the project.

We do rewrite large infrastructure software. We do. All the time.

[mathattack]

It isn't just that people depend on the features, you frequently lose track of which features were created for who, and for what reason. Sometimes it's just easier to keep things in motion, rather than start over and wait for someone to scream. (A case can be made for both)

[RogerL]

Right. I do not argue that rewrite is always the right thing to do; indeed, I argue that very most often it is the wrong thing.

But, answer me this. How many companies have imploded because their software was not maintainable? That's the other half of this article (Joel only wrote half an article, I contend). You can no longer make competitive bids for work because your impossible to understand. It takes months for the simplest change. Your customers leave in droves because your code is endlessly buggy, and you are pouring money into the drain of bug fixes that just introduce new bugs. Or, it is just a long drawn battle, as your profit margins slowly erode away as each new feature becomes incrementally more expensive to implement, until you are at negative return.

I say again; we have massive empirical evidence that total rewrites of very large infrastructure works. If you don't do it, your competitors will do it for you. And, of course, if you do it when there is no competitive need for it, you will be flushing money and/or your company down the drain.

(edited to fix some grammar and clarify a few poorly worded points)

[mathattack]

I wish good data existed on this, but most would be confidential, and this is very hard to measure to begin with. Ultimately it's a judgment call. There isn't a black and white, but Joel is giving a Year 2000 plea that people at the time were tilting the wrong way.