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:
dbf=dbopen("BBSUERS.DAT");
What you could not do was change the case of the filename:
dbf=dbopen("bbsusers.dat");
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
dbf=dbopen("BBSUSERS.DAT");
#else
dbf=dbopen("bbsusers.dat");
#endif
Which makes the code harder to follow. Forget:
#if defined(MSDOS) # define F_BBSUSERS "BBSUSERS.DAT" #elif defined (UNIX) # define F_BBSUERS "bbsusers.dat" #else # error Please define filename for system #endif ... dbf=dbopen(F_BBSUSERS);
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:
- Links that involve unauthorized use of our logo
- Framing, inline links or metatags
- Hyperlinks or a form of link that disguises the URL and bypass the homepage
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.
