
Bloatware and the 80/20 Myth (2001) - shawndumas
http://www.joelonsoftware.com/articles/fog0000000020.html
======
sliverstorm
Joel writes this like bloat doesn't exist, and discusses how programs are
large because of all the features they have.

Two contrasting examples spring to mind:

\- Outlook 2010 in Exchange mode usually occupies about 50MB of memory, at
least for me. Think of all the functionality Outlook 2010 has in those 50MB.

\- An old notebook I used a few years ago had a disk-parking feature, in case
of drops. The service application that parks the disk (if my memory serves)
would occupy about 200MB of memory. Think of all the functionality this
program had. It could stop the disk. It could start it. Fantastic.

That's bloatware. Especially as I had 2GB of RAM at the time.

P.S. Yes, many over-large programs can get swapped. No, swap is not a magic
solution, and happily tanks performance.

In summary, I do agree with many of the points Joel makes, but I always hope
that programmers at least _think_ about memory implications, if only for a
little bit. Some co-workers and I were discussing a small utility we were
developing. A very simple, fast structure was suggested. We then took a moment
to consider memory, and realized in our expected worst-case workload, the
process would require upwards of 64GB of RAM. This is why you need to spend at
least a moment thinking about memory! It is cheap, but not infinite, and oh-
so-easy to chew through _gobs_.

~~~
colanderman
My wife's HP laptop had some software that monitored the "audio mute" key so
it could turn the associated LED on and off. That herculean task required a
constant 50% of the CPU.

~~~
sliverstorm
To make matters more amusing, this laptop was in all probability dual core,
which means the software was pegging one of the cores.

~~~
colanderman
I think you are right.

------
quanticle
The more I read Joel Spolsky, the more I realize how wrong he is. He's like
the Thomas Friedman of software. He writes lots of things that sound good, but
aren't actually true.

For example:

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

Every single part of that statement is false. Your programmers _should_ be
worrying about how large their code is. If they're not, and your competitors
are, then your competition will release a program that does everything your
program does, but better and faster. So what if they're a couple months (or
even a few years) behind? First mover advantage is relatively short-lived,
anyway. Microsoft Word wasn't the first word processor and Microsoft Excel
wasn't the first spreadsheet. Google wasn't the first search engine. Facebook
wasn't the first social network.

As far as more features being helpful when you use them and harmless when you
don't, well, that's inaccurate too. I find it very ironic that he uses Excel
as his poster child for this, since the addition of features has absolutely
hurt Excel's usability. These days, Excel is a tool that's comparable to vim
or emacs. It's very powerful, but it has a ferocious learning curve to match.
Moreover, he overlooks the fact that more features mean more bugs. I think the
success of various web-based, minimalist tools has shown that users are quite
willing to accept fewer features, if the features that are present work
flawlessly.

And even the points that were true as of publication (e.g. ever shrinking
prices for CPU cycles and RAM) are no longer true today. If you're writing
code today, CPU cycles are definitely not free. You get roughly 4 billion
cycles per core per second on a desktop, and somewhere between 1 and 2 billion
if you're on a mobile device. Memory is slightly less constrained, but it's
rare for desktops to ship with more than 8 GB of RAM, and it's unheard for
mobile devices to have more than 1 or 2.

So no, I don't think bloatware is a "mental health problem". I think it's a
real issue, and one that's only going to get worse as we run into the limits
of Moore's Law.

~~~
jmduke
_Every single part of that statement is false. Your programmers should be
worrying about how large their code is. If they 're not, and your competitors
are, then your competition will release a program that does everything your
program does, but better and faster. So what if they're a couple months (or
even a few years) behind? First mover advantage is relatively short-lived,
anyway. Microsoft Word wasn't the first word processor and Microsoft Excel
wasn't the first spreadsheet. Google wasn't the first search engine. Facebook
wasn't the first social network._

You're equating code size with code quality, which in my opinion is an
unqualified assumption. I'd further argue that its not as if programming hours
exist in a vacuum, and its not as if one makes a binary choice whether or not
to spend time reducing code size; development time is a precious, precious
thing. When given the choice between:

\- reducing the size of Microsoft Excel from 15mb to 14mb -- and thus
increasing sales by X, where X is the number of people who had hard disk space
for 14mb but not 15mb

\- and implementing some sort of stretch goal feature (let's call it
PowerPivot v0.0.1), and thus increasing sales by Y, where Y is the number of
people who make their spreadsheet software purchase decision based on the
presence of that feature

I'm fairly confident X < Y.

~~~
quanticle
_You 're equating code size with code quality, which in my opinion is an
unqualified assumption._

Unfortunately, most of the software engineering literature disagrees. We know
few things in software engineering. One of them is more code == more bugs.

Your comment about X > Y is true, but you're replacing one false binary choice
with another. Again, as Apple has demonstrated over and over again with every
single one of their products, fewer features, implemented well will outearn
products that have more features implemented poorly.

So, I'd argue that the choice isn't between reducing the size of Microsoft
Excel from 15MB to 14MB and adding a stretch goal feature. It's between
_keeping_ Excel at 14MB (or whatever its old size was), fixing bugs and
polishing the hell out of it or _growing_ Excel to 15MB and adding some more
buggy half-assed features to fill out the checklist on the back of the box.

~~~
gruseom
_Unfortunately, most of the software engineering literature disagrees. We know
few things in software engineering. One of them is more code == more bugs._

Quite so. I wish there were more research into the consequences of this. And
more teaching of it too, for that matter. It ought to be a much bigger deal
than it is.

------
jlgreco
_" Ohhh. It eats up all your memory. I see. Actually, well, no, it doesn't.
Ever since Windows 1.0, in 1987, the operating system only loads pages as they
are used. If you have a 15MB executable and you only use code that spans 2MB
worth of pages, you will only ever load 2MB from disk to RAM."_

This is such a bullshitty argument. The chance that the pages that you need to
load to accomplish a simple task _(say, adding up 20 numbers)_ with a program
capable of doing many many things _(say, excel)_ will be comparable to the
number of pages that you need to load to perform the task in a far more
limited program _(say, `dc`)_ is infinitesimal. In practice, it just isn't
going to happen.

Using small programs to accomplish small tasks is what Linus Åkerlund was
arguing in that post
([https://web.archive.org/web/20000305231633/http://user.tnine...](https://web.archive.org/web/20000305231633/http://user.tninet.se/~uxm165t/bloatware.html)).
Now, there are _very obvious_ reasons why "the UNIX way" is not for everybody,
and why monolithic featureful programs have their place, but Joel is
delusional if he thinks that Linus is incorrect in practice on the memory
usage point.

I bet I can start and close 'dc' several thousand times in the time it takes
Excel to start once. Not a fair comparison by any measure, but nevertheless
one that Joel invites by attacking Linus' article.

------
jakobe
I strongly disagree with Joel here. It's true that storage is much cheaper
today, but every piece of software I use is downloaded from the internet. Not
everyone has 10MBit connections. If you make software, and especially updates,
unnecessarily large, you will cut off a percentage of your users.

I'm not saying you should axe features to make the app smaller. But please, if
you distribute software, spend a few hours and try to make the download size
as small as possible.

~~~
ben336
Note that this was written in 2001 when the statement "every piece of software
I use is downloaded from the internet" would have been ridiculous at the time.
Not saying your point isn't valid, but just pointing out that its not
something that should have been addressed by the article.

~~~
jlgreco
> _2001 when the statement "every piece of software I use is downloaded from
> the internet" would have been ridiculous at the time._

Not for the sort of people that he is arguing against in this post, such as
Linus Åkerlund who is arguing for using computers "the UNIX way" with
GNU/Linux. Downloading your distro from the internet was very old-hat by 2001.

------
charlesism
Joel is probably my favourite tech blogger. That said, some perspective on how
old this post is:

2001 - 1993 == 8

2013 - 2001 == 12

------
jacques_chester
The 20% thing is interesting, but Microsoft themselves later empirically
established through application usage metrics that there is an _ordering_ of
features.

That is, some features (eg, italics) are used more than others (eg, macros).
Such an ordering can be used to established, with considerable confidence, the
"20% that 80% of customers use".

Which is how we got the Ribbon. It was intended to place the most commonly
used features front and centre.

~~~
jlgreco
I remember I once spent a good 10 minutes trying to find "print" in microsoft
word, with it's ribbon. I knew I could just hit ctrl-p of course, but I kept
at it because I was baffled at how hidden it was. IIRC, I eventually found it
in a menu, not in the ribbon, that appeared if you clicked some button on the
top left.

I refuse to believe that much design work went into that infernal thing. I am
sure somebody _billed_ a lot of design time for it, but were they actually
putting thought into it? I doubt it.

~~~
yuhong
Office 2010 finally restored the file menu.

------
officemonkey
15 mb?

I was using Excel on the Macintosh for laboratory analysis as early as 1987.
It could run on two 800K floppies. So, 1.6 mb. It had 80% of the functionality
I ever used Excel for.

~~~
pilsetnieks
The version of Excel mentioned in the article was Excel 5.0 for Windows, that
came out in 1993. No one is denying that previous versions were been smaller.

~~~
officemonkey
The old submission title seemed to indicate that Excel came out in 1993 and
was 15 mb. Someone has since corrected the title.

------
gbog
I think both the article and the comments miss the point. If you take a Linux
distro, it is actually bloated, in the sense that it has a lot of useless
stuff that take space. However, it's built on a solid, stable architecture
which allow bloat management. Same with vim: I have seen vim setups that are
complete bloat, with hundreds of plugins, and even plugins managing plugins.
But this is managed, manageable, because based on a well defined base.

There is a comment about Django: yes, bloated and managed, because it is based
on python, which is the same, a minimal and solid set of orthogonal concepts
upon which bloat is easily managed.

------
peterhunt
This really nicely sums up why I use Django for every Python web project I do
instead of something like Flask. Django's size doesn't negatively impact me in
any way and the fact that it has so many features and a huge number of
libraries and docs means I'm less likely to need to do a lot of building when
requirements change.

I think this extends to anything that calls itself a microframework -- being
small isn't a meaningful feature unless it actually impacts your app.

------
drill_sarge
The only real bloat I know are vendor specific programs that come for free
with certain hardware. I don't know who writes such shit sotware. From the HP
Windows driver suite (not the driver itself but all those useless programs
which come along with it; funny enough hplip is the best thing on linux),
horrible tools which come with motherboards ("omg make the ui look like it is
a spaceship cockpit"), shitty tools from laptop manufacturers for wlan,
bluetooth and so on. who the heck writes these!?

Commercial programs are mostly not bloated and don't scatter around the whole
system.

------
dotBen
Also note, this article was published in 2001. If disk storage was cheap then,
it's an order of magnitude (or more) cheaper now.

~~~
jlgreco
It is cheaper, but probably not by as much as you might think since many
people are transitioning to SSDs which set us back several years in terms of
price and capacity.

My case is extremely non-typical, but my current primary computer has 30 GB of
storage, which coincidentally is what my primary computer had about one decade
ago (of course this is _much_ faster, in a laptop, and I have I have a very
large amount networked storage available to me...)

------
tonylemesmer
Word processors should load instantaneously. Photoshop should load
instantaneously. Windows should load. Instantaneously.

------
tn13
Before you comment please note that this article was written in 2001 almost 12
years back.

------
whyenot
When I was using Word on the Mac in 1992 (version 5? 6?), it even had it's own
built in screen saver... I guess in case you didn't want to look at flying
toasters or whatever.

~~~
yuhong
Ah, Word 5.1 for Mac.

------
koudi
Yeah, storage is cheap, let's go wild and add some features that might be
useful for a handful of people. Reminds of time when excel had simple flight
simulator in it...

------
softworks
So it's like excel is getting smaller? Come in please. Sounds like some of
that "new math" to me....

------
eriksank
... _and then the journalist tries to find the "word count" feature which they
need because most journalists have precise word count requirements, and it's
not there, because it's in the "80% that nobody uses_...

The solution is not to ship a half-baked "word count" feature by default, that
some journalists will like and others won't, but to make sure that the
application is thoroughly pluggable.

From there, people can set up entire plugin repositories in which journalists
can find dozens of plugins that all specifically apply to journalist
situations.

Why not have our cake and eat it too? We'll have a very small core
application, while everybody can click and install whatever extensions that
apply to their specific situation.

Furthermore, why would non-journalist users have to deal with journalist-
specific plugins installed by default? It would just confuse the 80%.

Bloatware is NOT the solution to the "80/20" problem. This is and example of
the real solution:

[http://plugins.jquery.com](http://plugins.jquery.com)

~~~
trentmb
> Why not have our cake and eat it too? We'll have a very small core
> application, while everybody can click and install whatever extensions that
> apply to their specific situation.

That's an operating system.

