The Boston Diaries

The ongoing saga of a programmer who doesn't live in Boston, nor does he even like Boston, but yet named his weblog/journal “The Boston Diaries.”

Go figure.

Tuesday, Debtember 04, 2001

Joel on Bloatware

SMS: Joel, what, in your opinion, is the single greatest development sin a software company can commit?

Joel: Deciding to completely rewrite your product from scratch, on the theory that all your code is messy and bug prone and is bloated and needs to be completely rethought and rebuild from ground zero. SMS: Uh, what's wrong with that? Joel: Because it's almost never true. It's not like code rusts if it's not used. The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they've been fixed. There's nothing wrong with it.

An Interview with Joel Spolsky of JoelonSoftware

I've been pondering this article for the past few days as I worked on my project and I still feel Joel is wrong about this.

Yes, it does cost if existing code is scrapped and a rewrite is done. But I suspect it's not done correctly—with the original authors who learned the hard way what does and doesn't need to be done. It's done with another set of programmers who have little (if any) contact with the original authors so any important information (like Microsoft IIS servers that send out bad Location: headers) is lost.

That's why it costs so much.

And yet, I've done it. I've rewritten the same program three times over (once to switch implementation languages) and each time the code base has improved over the previous version. The latest version had a better base upon which to make modifications (but it's moot since no version of the program is in use, but not for maintenance reasons).

And the cases Joel uses as examples are well known cases where a rewrite was disasterous, but what of NT? That was based upon an entirely different code base than Windows 3.1 and even my most anti-Microsoft friends admit that NT 3.51 was rock solid and well designed (and had nothing in common with Windows 3.1 or 95 except the API). OS/2 2.0 was a rewrite and vastly better than OS/2 1.x.

The sheer volume of bugs, it seems, proves that rewriting code from scratch does not make for a better code base, it makes it worse. Old code doesn't rust, it gets better, as bugs are fixed. Lou Montulli again: “I laughed heartily as I got questions from one of my former employees about FTP code the he was rewriting. It had taken 3 years of tuning to get code that could read the 60 different types of FTP servers, those 5000 lines of code may have looked ugly, but at least they worked.”

Joel on Software—Netscape Goes Bonkers

And I bet those 5,000 lines of code where a nightmare to maintain. Lou Montulli probably laughed because he didn't have to maintain that codebase anymore. Yet another project I worked on involved a program written by a college student that was so poorly written I can't even begin to describe how bad it was (let's see, in C, but with random indentation, poor variable name choice and could produce garbage in rare but most likely inevitable circumstances). Even the original author refused to help (“Hey, I got paid, man! I'm not touching that fXXXXXg code again! He [the customer] got what he paid for!”). So it was without ceremony (since the author was too far away to sacrafice) that I dumped the code and rewrote it from scratch.

SMS: Yes, but isn't such code tight and small? Don't products built this way avoid the dreaded “bloatware” label?

Joel: Don't get me started! If you're a software company, there are lots of great business reasons to love bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner. And that means you get more features, and features make users' lives better (if they use them) and don't usually hurt (if they don't). As a user, if your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible, but you went for two months without new features that you needed, and THAT hurt.

An Interview with Joel Spolsky of JoelonSoftware

Now, Joel worked for years at Microsoft, so he's biased, but here's a reason as a customer to hate bloatware: You don't have to buy a new computer every two years! You have more resources to store and process your data, not to store bloatware. The software might actually run faster, or run acceptably on something less than the greatest and latest.

But as Bill Gates has said—there's no money in fixing bugs, only in features.

Rememberances of code past

I did work at a company where I was helping to port their product from MS-DOS to Unix. One of the mantras at the company was Thou shalt not change code! And they meant it. And it was taken to silly extremes.

One example: filenames. Under MS-DOS the case of a filename given to MS-DOS doesn't matter as MS-DOS will convert it to uppercase, so specifying README or readme gives you the same file. Unix though, is case sensitive so README and readme are two different files. The company decided that all filenames under Unix were to be lower case, but at various points in the code there might be a file specified all in upper case:


What you could not do was change the case of the filename:


No. That might break. How, I don't know. But the mantra was Thou shalt not change code! So the proper way to do it was:

#ifdef MSDOS

Which makes the code harder to follow. Forget:

#if defined(MSDOS)
#elif defined (UNIX)
#  define F_BBSUERS	"bbsusers.dat"
#  error Please define filename for system



That's a major code change (even though it doesn't clutter the code flow with compilation changes). I do think that the Unix manager did manage to get:

char c;

changed to

typedef unsigned char Char;


Char c;

But that may have been the only concession to Thou shalt not change code! that was made at the company.

For some reason, I'm reminded of this because of Joel. Go figure.

Clueless lawyers? Or subtle marketing trick?

The following web link activities are explicitly prohibited by KPMG and may present trademark and copyright infringement issues:

Via MetaGrrrl, Global Legal Disclaimer

Am I now going to get a notice to remove the link? Oooh, I do so much want one. AutoZone didn't seem to have a complaint about my linking to them but then again, I'm not using their logo.

And in the case of KPMG there, since I'm not using their logo ( … must … resist … urge … to link … to … their … logo … ) and I'm not disguising the URL and bypassing their homepage (I am bypassing their homepage up there, but I'm not disguising the URL) so the only thing left is that rather cryptic bit about “inline links,” whatever they mean by that.

Also in their disclaimer, they say “KPMG is obligated to protect its reputation and trademarks and KPMG reserves the right to request removal of any link to our website.” Yup. You (KPMG) have that right, but that's all you have. You're trashing your own reputation on the web just fine—you don't need anyone else to help you there.

Obligatory Picture

[It's the most wonderful time of the year!]

Obligatory Contact Info

Obligatory Feeds

Obligatory Links

Obligatory Miscellaneous

You have my permission to link freely to any entry here. Go ahead, I won't bite. I promise.

The dates are the permanent links to that day's entries (or entry, if there is only one entry). The titles are the permanent links to that entry only. The format for the links are simple: Start with the base link for this site:, then add the date you are interested in, say 2000/08/01, so that would make the final URL:

You can also specify the entire month by leaving off the day portion. You can even select an arbitrary portion of time.

You may also note subtle shading of the links and that's intentional: the “closer” the link is (relative to the page) the “brighter” it appears. It's an experiment in using color shading to denote the distance a link is from here. If you don't notice it, don't worry; it's not all that important.

It is assumed that every brand name, slogan, corporate name, symbol, design element, et cetera mentioned in these pages is a protected and/or trademarked entity, the sole property of its owner(s), and acknowledgement of this status is implied.

Copyright © 1999-2021 by Sean Conner. All Rights Reserved.