Thursday, 29 March 2001

Bloatware

Listening to:

Beethoven, sonata no. 3 in A, op 69 for piano and cello.

A recent movie:

Toy Story II. I saw this at home on DVD recently, and thought it was brilliant. It has a rather gag-inducing song in the middle about a girl growing up and abandoning her toys, but it's otherwise extremely amusing and entertaining. On DVD, we also got to see a bunch of interviews with some of the actors doing the voices, which was kinda neat.

Joel gets it wrong

I’m going to link to Joel Spolsky again today, but this time I come not to praise him, but to bury him. His latest article is about bloat-ware. This is the phenomenon that sees the 1993 installation of Microsoft Excel take up 15 MB of disk-space, and the version for 2000 take up 146 MB. He dismisses complaints about this problem by saying that the decreasing cost of hard-disk space has more than made up for the increase in size, so that in terms of its space-consumption cost, the 2000 version of Excel is actually cheaper than its predecessor. He also dismisses complaints about the fact that big programs have a memory-consumption cost too (some part of them needs to be loaded into memory); pointing out that paging and virtual memory combine to ensure that you may not often have much of the executable in memory at any one time, and the rest will be consuming more of that cheap disk-space. Further, this means that start-up times for the application will likely be pretty good.

So far, so good. This stuff is all perfectly correct. But it’s not the real reason to feel annoyed about bloatware. My objection to it is that it’s a sign of poor craftsmanship. Does Spolsky really think that it's admirable that at least some versions of Excel include a flight simulator Easter Egg?

He explains bloatware thus:

In fact there are lots of great reasons for 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 your life better (when you use them) and don’t usually hurt (when you don’t). 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. Maybe, just maybe, if you tend to keep your hard drive full, that's one more Duran Duran MP3 you can download.

That looks like one dodgy reason to me, not lots of great ones. If shipping software quickly is the overriding concern, then the result may well be better results for the company producing the code, but what does the consumer get? Insufficiently debugged, poorly tested code that crashes more than it should. Maybe all of those features that have been pushed into the new program are interacting in subtle ways with the flight simulator. Maybe the fact that several versions of the same library code have been linked with the application is an indication that the people developing the code didn't really have any idea about what they were doing when they wrote it.

Would you buy an operating system from these people?

Comments