Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Bloatware and the 80/20 Myth (2001)

joelonsoftware.com

Post reply on HN
Print view View original

41–50 of 59 posts

Re: Bloatware and the 80/20 Myth (2001)

#41

Post by themodelplumber »

quanticle wrote: post #23

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 (…

>> if programmers don't

> Every single part of that statement is false. Your programmers should be

Uhh...you're saying they "should be worrying" and he's saying they don't have to be. Those are not mutually exclusive positions.

> As far as more features being helpful when you use them and harmless when you don't, well, that's inaccurate too

Second time you made a statement after this fashion--I see the pattern. Your position is that Spolsky is not allowed to write about things that other people do that are wrong.

> So no, I don't think bloatware is a "mental health problem". I think it's a real issue

Pretty sure Spolsky feels that way too! What an argument.

Re: Bloatware and the 80/20 Myth (2001)

#42

Post by jlgreco »

jacques_chester wrote: post #11

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 commonl…

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.

Re: Bloatware and the 80/20 Myth (2001)

#43

Post by oakwhiz »

colanderman wrote: post #6
sliverstorm wrote: post #2

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 applicatio…

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.

A whole CPU just for a single GPIO task? Now that's bloat.

Re: Bloatware and the 80/20 Myth (2001)

#44

Post by 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

Re: Bloatware and the 80/20 Myth (2001)

#45

Post by jlgreco »

dotBen wrote: post #21

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

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

Re: Bloatware and the 80/20 Myth (2001)

#46

Post by quanticle »

jmduke wrote: post #40
quanticle wrote: post #23

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 (…

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 wor…

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.

Re: Bloatware and the 80/20 Myth (2001)

#47

Post by gruseom »

quanticle wrote: post #46
jmduke wrote: post #40

Earlier quoted context omitted.

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 wor…

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 t…

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.

Re: Bloatware and the 80/20 Myth (2001)

#48

Post by yuhong »

jlgreco wrote: post #42
jacques_chester wrote: post #11

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 commonl…

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…

Office 2010 finally restored the file menu.

Re: Bloatware and the 80/20 Myth (2001)

#49

Post by officemonkey »

pilsetnieks wrote: post #14
officemonkey wrote: post #7

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.

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.

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

Re: Bloatware and the 80/20 Myth (2001)

#50

Post by trentmb »

eriksank wrote: post #44

... 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 ca…

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

Post reply on HN