Joel writes: > In fact there are lots of great reasons for bloatware....

and then cites exactly two: shipping sooner, and jamming the box full of features, each of which somebody, somewhere cares about.

The shipping sooner part is a bit odd: more features means ships later, I'd guess, with the time-to-deliver worse than a linear function of features added.

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

Ok, the "squeezing code" activity is not all that productive, but this little thing you skipped over so blithely is at the heart of my argument against bloatware: more features make the ones you want harder to find. More features make it more likely that the code will ship with untested interactions that make the program and/or the operating system stop working.

Size is not a good metric pro or con. Supposing that big software is better, since it must have more features is just as narrow-minded as supposing that a big program is inherently bad.

As an example, Zawinski's quip would be more persuasive if it were really true that "there are lots of small, lean web browsers out there that, incidentally, do almost nothing useful...." Microsoft seems to have realized they tried to put too much in the box with MSIE v4, for example, and backed off with v5.

-- Anonymous, March 23, 2001

Answers

So, do you still think bugzilla is a piece of bloatware?

-- Anonymous, March 24, 2001

In Defense of Bloatware

I agree with Joel. I think people assign the term "bloatware" to applications, not just by their disk-space requirements, or the amount of resources they use, but by subjective measures, like, "The last version used to only take two seconds to load, and now it's taking five! It's getting so bloated..."

"Bloat" is really a false attribute, what we assign to an application when we begin to sense a vague feeling of dissatisfaction with its performance -- when the symptoms may be caused by factors other than the application itself. This is like attributing to objects the quality of Goodness or Badness, when we're really describing our own internal experience, not the objects. "Bloatness" is, maybe, a symptom of a kind of neo-Platonism.

But Joel's perception of application performance may differ markedly from those who aren't running state-of-the-art systems. I'm sure he's never seen bloated applications, because he's run them on a system they were meant to be run on. If I were running a Windows 98SE on a 155-MHz system with 8 MB of RAM, everything, including RegClean probably would seem outrageously bloated. Oh, you have a 1.5+GHz, with 256 MB RAM? Oh well, then, everything must seem to be running pretty lean and mean, huh.

The real cause of our dissatisfaction might stem from poor system maintenance, including a BLOATED Registry. Joel, yes, it happens. My last machine had a USER/SYSTEM.DAT that was almost 24 MB, before I reformatted and re-installed -- it's now about 5 MB. And I USED RegClean on it religiously, too. But, believe me, I WAS BLOATED. I don't know WHERE the software was bloated, but it was BLOATED. I was taking forever to load anything, and crashing to BSODs literally every 10 minutes, if I was lucky. BLOAT, it was the BLOAT. Bloated bits and bytes.

Joel doesn't have a bloated Registry, and probably never did. His machine is probably not crammed with "family programs," old outdated educational programs, games that install old DLLS over your fresh Windows 2000... Oops, I forgot, he's probably running Windows 2000 or XP, which protects against version retrogrades. See?

Oh, but you see, we can't place the blame on one's choice of operating system, or our two-year old hardware. We're poor consumers, and don't understand that we shouldn't get that new version until we upgrade our system. It's too easy to just get that one more piece of software, that new version upgrade. Software Drives The Hardware, Bill proved that Apple was wrong. We prove him right too, when we upgrade to the new version meant for faster machines, discover that hey, it's BLOATED, then eventually, grudgingly, upgrade our systems. Then we forget that the same software on the new machine was bloated. Hmm. It must have lost some weight since I got this new machine...

The blame has got to be puttable on something or someone else. Why blame yourself, or your ignorant consumer choices, when you can blame the Anonymous Programmer.

The final remedy for bloatware is to get a system that was designed for the application versions you run, and to keep the crappy, buggy stuff off, put it on the kids' machines. But we'll always have bloatware, because we'll always have the Anonymous Programmer to blame.

-- Anonymous, March 24, 2001

It is obvious that the meaning of the term BLOAT changes with context but it is generally this, if the software requires more of something that I don't want to give up, then its BLOATED! IF the software takes 5 seconds to load but I get bored in 3 then it is BLOATED. If it requires 200 megabytes to load and I 1 gig left but I still need to load ALL of my vacation photos and I need that 200 Meg, well then it is BLOATED!

This has always been the case and it always will be. Trying to eliminate bloat is a wasteful. The focus should simply be on practically efficient code and bug prevention.

One of the responsibilities I have with my employer is that of Help Desk support. From that perspective I would like to suggest another view of BLOAT. I will call it "Feature Visibility Bloat".

Joel's assertion is correct that the 20% feature set will never be the same 20% of the total features. IF you want to sell software you need 100% of the features that users want, and want is the same thing as need, keeping in mind of course the intended target user community.

So...the products we use get shipped with thousands of features even though the users I support will only use about TWO of them! What happens is this;

The user is happily (or begrudgingly) typing up a letter to a customer when they notice that a word they just typed is marked with squiggly red underline. The user right-clicks on the word and up pops a menu of choices they have only seen once, about 3 months ago. The user looks over the options and, perhaps because they are bored, they notice one of the menu options and think it looks "interesting".

So the user clicks on the interesting item and finds a whole new world of options and "fun stuff". After turning on what they think will be useful options they finally get back to correcting the spelling or grammar or whatever and finally complete the document.

A few days or weeks or months go by and the user is again composing a letter or something. Everything goes fine until, at the end of the session the user decides that the entire document needs to be double- spaced or in some unusual font or this one word needs to vibrate or something. A few clicks of the mouse an finally the document is perfect, except for the fact that every paragraph is indented wrong or outlines are not numbered (and they always were BEFORE!) or something else is wrong and the user didn't expect this.

Of course the first thing the user does is recall that 3 months ago they changed a feature or option by choosing MENU1/MENU2/MENU3/ITEM2/TABWhatever/Region3/Options2, 5 and 9, so they simply undo the change. WRONG! They call the Help Desk and try to explain the problem in just so many "hundreds of words". So you go through the whole diagnostics process and finally walk them through the steps to turn off the options that they turned on 3 months before. Of course they don't recall making such changes so the software must have flaked out. A little confidence in the software is lost, not to mention 30 minutes of staff time times 2 occurrences per year times 400 users times 10 applications and suddenly we are talking about 4,000 hours per year, which equates to maybe $60,000.

I would propose that only a very few features be activated and visible to the end user as a factory default. During setup there could be a wizard that helps fine tune the visible feature set. Perhaps asking the user questions such as "Which of the following industries best describes your company's business?" and "For who many years have you been using word processing software?" and "Which of the following is the correct definition of blah-blah-blah?".

The point is to hide ever feature that the user does not understand. Tie the help system into the feature setup wizard so that when the user starts looking for a feature they can be guided to just that one feature and the wizard can set it up based on the user's level of proficiency.

The BLOAT problem is not that there are too many features, it is that they are all visible and do not take the user's context in to consideration!

-- Anonymous, March 24, 2001

As Joe Nieter says, "the meaning of the term BLOAT changes with context." Too big, or too complex or too buggy are all relative to something - my disk space, my RAM, my operating system, etc. For example... I don't find Excel (up through v97, haven't used 2k enough to state an opinion) particularly bloated, because it's fast enough, small enough, and simple enough for me to get work done with it without thinking too much about the tool. I do find Word (again v97) to be bloated/too big/too complex/too buggy, because there's almost nothing I can do with it that doesn't require me to wander through menus, consult its Help or experiment to get what I want. Understand that I don't even consider using it unless it's to read a document someone sent me (it usually works for that, but Acrobat/PDF typically work better), or to generate something more complex than plain text email or HTML. Case in point last week - (Long story if you're interested, I'll put it at the end.) Joe's estimate of the cost seems about an order of magnitude low: "... and suddenly we are talking about 4,000 hours per year, which equates to maybe $60,000." The round number rule of thumb I use for engineering time ("fully loaded," as they say) is $100/hr, not $15. And problems often escalate beyond 2 people for half an hour in my experience. "Oh you just need to reinstall (choose one: the operating system, the application, an o/s service pack, an application patch, etc.)" Mike Lee asks:
So, do you still think bugzilla is a piece of bloatware? I'm not sure which code I'd be commenting on. After being a loyal Netscape user for many years, the bugs in v4.7x and the wait for a v5 got to be too much to take for a browser. I still use it for a Newsreader, but I don't need or want it for email, or HTML editing. The one feature I looked for an HTML editor to provide is ease of table manipulation, and NS never seemed to get there. Some irony in that its internal overuse of tables broke so much of its CSS compliance. As for the open source or v6 efforts - I wish the writers the best of luck, because I think it's essential to have multiple viable sources for a browser, but I'm too busy to beta test large pieces of software that I need for day-to-day work.
_____________
Tom von Alten http://fortboise.org/ Here's today's long bloatware story:
I had the need to combine text, some CAD drawings, and some algebra that I'd done in MathCAD. Word seemed like it could be the right tool. The corporation I work for hired some whizzy consultants to design stationery, and it comes in Word templates. It also comes with some stupid and awkward design choices, like having all its content in tables. Ok fine, I've worked with Word's tables, and I rather like a two-column style with topic headings on the left. Oh but wait, when this cell here gets too much text, it wants to all go to the next page, and leave 2/3rds of page 1 white space. The table formatting has "allow row to break across pages" set, what's going on? And now what was that trick to get an image to stay where I put it on a page? Float over text on or off, and what other settings? And so on. It was annoying, but I can get through it. Then I get all done, and go to print, and... Application Exception, Word crashes and burns. Fortunately, I'd been saving regularly, and didn't have to recreate anything, but restarting, and re-attempting to print reproduced the crash. I copied the composed text into vim and produced the document in HTML in about as much time as it took to send the offending .doc to the local Help desk and ask if they could figure out what was wrong with it. Later, I found out that with a clean boot and a clean start, I could print one or two copies before it would start crashing. Must be a memory leak in there, somewhere, eh? No doubt a patch more recent than the X patches and reinstalls I've had would fix it. Or, as the Help desk guy said, I could "upgrade" to Office2000. Maybe with that I could print half a dozen copies before it would crash.

-- Anonymous, March 24, 2001

Oh my god that was ugly. So much for my guess about what formatting was possible with this software. :-( It would be nice if it were documented somewhere... even a "you can't do anything like that, don't try" would be appreciated.

-- Anonymous, March 24, 2001

Joel, your latest article is magnificent!

I've found myself in such discussions before; iCab vs. Mozilla. And, yes, it's true - Mozilla takes up more memory, yes, and it requires more diskspace but it's so much better than iCab!

And what does iCab do? It barely support such a vital part of a browser as Javascript, and it's UI is awful. At least there is a variete of Themes you can use for Mozilla.

Thanks for this article Joel.

-- Anonymous, March 24, 2001

What's the need to dissect issues such as 80/20? I've also had a lot of discussions about that matter but, tired and conscious of the need to live-on, I decided to only page over that discussions and continue with the work I've to get done. And yes, Joel's comments about this are the best he's written in a long time. I'm forcing myself to always read his opinions altough I nearly always disagree (specially when "guruing" against the all-mighty MS.

-- Anonymous, March 24, 2001

Bloat is an indicator of a second-order problem. It suggests that someone in the process is cutting corners and isn't cleaning up after themselves. It might not hurt the product now, but it accelerates ossification. Bloat charges interest.

-- Anonymous, March 25, 2001

I agree with Joel that large space requirements are not a big deal if the hardware is up to the level of software. I just got a new 900 MhZ computer, with a 20 GB hard drive for what seems quite a cheap price. I'm thrilled to load all the software I can on this machine.

The danger is for those with an older computer they are loath to upgrade. With the exponential pace of technology growth, it takes only about 2-3 years before there are significant problems with adding software to an earlier machine.

I'm terrified to put most new software on my other computer, a 166 pentium with 64MB of memory. It'd be nice if I could get "Lite" versions of current applications, rather than have to replace all my hardware for every new generation of software.

--> WILL

-- Anonymous, March 26, 2001

Dave is right on the money: Bloat is an indicator of a second-order problem. I don't care that Excel takes up a ton of disk space, but a development environment that allows that bloat likely allows people to be equally lazy when it comes to other "useless" optimizations. Why does it take 10 seconds for ICQ to launch? It must be doing all kinds of useless things. If they were forced to make their executable smaller, they'd be forced to make their code simpler (though not by sacrificing features), and two side effects of that would be faster code and more robust code. Bloat hides bugs.

The right way to add lots of features is with loadable modules. See Perl modules, Emacs, or Linux kernel modules. If you don't need them, you don't load them. That means they don't slow down your CPU when the program loads, they don't slow down your CPU when your program runs, you don't have to wade through their options or namespace cluttering if you don't need them, and you don't have to worry about their bugs.

-- Anonymous, March 27, 2001

I wonder how many MS Word users really write macros to increase productivity. There's an example of a ``feature'' whose legitimate value, calculated by the amount of real work done by real users, is probably nil, but whose unintended side-effect (viruses) was and continues to be vastly negative.

-- Anonymous, May 27, 2001