Also note, this article was published in 2001. If disk storage was cheap then, it's an order of magnitude (or more) cheaper now.
Bloatware and the 80/20 Myth (2001)
21–30 of 59 posts
Re: Bloatware and the 80/20 Myth (2001)
#22This 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.
Re: Bloatware and the 80/20 Myth (2001)
#23The 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.
Re: Bloatware and the 80/20 Myth (2001)
#24Earlier quoted context omitted.
> Which is how we got the Ribbon. It was intended to place the most commonly used features front and centre. So how come we ended up with something that placed all the features front and centre?
I'm not sure I follow you.
rcgs is referring to the way that Microsoft has, over time, added more and more buttons into the ribbon, so that at present most Microsoft applications have almost all their functionality accessible through the ribbon. rcgs would argue that this defeats the point of the ribbon in the first place (I'm inclined to agree).
Re: Bloatware and the 80/20 Myth (2001)
#25When 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.
Re: Bloatware and the 80/20 Myth (2001)
#26Word processors should load instantaneously. Photoshop should load instantaneously. Windows should load. Instantaneously.
Re: Bloatware and the 80/20 Myth (2001)
#27I 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…
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.
Re: Bloatware and the 80/20 Myth (2001)
#28I 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…
It was written in 2001... Software was mostly delivered by CD.
Re: Bloatware and the 80/20 Myth (2001)
#29Before you comment please note that this article was written in 2001 almost 12 years back.
Re: Bloatware and the 80/20 Myth (2001)
#30"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...). 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.