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...
Bloatware and the 80/20 Myth (2001)
31–40 of 59 posts
Re: Bloatware and the 80/20 Myth (2001)
#32Earlier quoted context omitted.
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).
Thanks.
Re: Bloatware and the 80/20 Myth (2001)
#33Earlier quoted context omitted.
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).
The ribbon is not designed to be an edited toolbar with a single row of just 10-20 functions. It's a wholesale replacement for application menus. Every new function and feature should have a placement on the ribbon, or else how would you otherwise activate it?
Organization of the ribbon is important, though, and it may take some time to learn where stuff is, or how it's organized. The first time I used it with Excel, I couldn't find the Pivot Table button. I thought it might be under [Data], but you're [Insert]ing a pivot table instead.
Re: Bloatware and the 80/20 Myth (2001)
#34Joel 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…
>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.
Ohh I wish my beloved thunderbird only took that much memory. I remember it occupied somewhere between 150-250MB on my netbook. It was impossible to keep it running in the background, especially when you only have 1GB of total RAM. My routine was to open, check for mail, close it.. rinse repeat.
Re: Bloatware and the 80/20 Myth (2001)
#35I 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.
> 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.
Re: Bloatware and the 80/20 Myth (2001)
#36I 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.
Re: Bloatware and the 80/20 Myth (2001)
#37Joel 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…
How could that app possibly use 200MB of memory? Was that resident memory or simply mapped memory?
Some sort of disk buffer, maybe?
Re: Bloatware and the 80/20 Myth (2001)
#38When 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.
Ah, Word 5.1 for Mac.
Re: Bloatware and the 80/20 Myth (2001)
#39The 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 (…
more processors are running on batteries too now and the improvements on those aren't keeping up at Moore's law pace.
Re: Bloatware and the 80/20 Myth (2001)
#40The 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 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.