Bob Zurek: Software Bloat! Ever get the feeling that you've had enough of the upgrade after upgrade and sometime continuous stream of hundreds of new features coming in the software you use? How many of these new features do you truely need? In fact it seems like some of these "new features" are not really new, they are just things that needed to be fixed or improved that are now called "new features". New features also sometimes mean more complexity, more disks, longer downloads, bigger help systems, more documents, more trips to the bookstore, etc. (more)
Bob, I agree with you in principal, but it's not such an open and shut case.
Joel Spolsky made the argument in his article Bloatware and the 80/20 Myth that if your product is successful, you'll have lots of customers. These customers will want different features from your software. If you prune out the features that you feel are gold-plating, innevitably someone out there will miss them.
So how do you give all of your potential customers all of the functionality they want yet not deliver bloat? Current software distribution technologies - product downloads, CDs, and (yipes!) DVDs only provide monolithic component configurations - i.e. "the whole shebang" - to satisfy all potential customer needs.
But what's the alternative? Provide the sub-components ala carte and let the customers weave together their minimum required set? Then customers would complain about complexity of installation (even more than they do today - rightfully so!)
It's basically a question of being able to deploy components more intelligently. In the web-based case this is relatively easy, because you can have as much gunk you want behind the scenes on the server yet only expose a small subset of the features to a particular user, using profile-based personalization and user-initiated customization. In the rich-client case it's more challenging, because the user actually needs components present and installed on his or her physical machine.
However, there is work being done on a so-called "server-managed rich client" that hopes to provision local rich-client components based on user needs, so that each user may have as many features as he/she needs, but only those features. The server handles the personalization, customization, dependency-management, and provisioning.
Though this technology is still under development, I believe it will become real, and I believe it will make big headways into software bloat.
PS - Ryan Tomayko and friends have been writing a lot of interesting stuff re: smaller and simpler software and programming languages on their web site lesscode.org. If you (the reader) are interested in fighting software bloat and complexity, you should definitely check it out.
contact me: email@example.com
Software bloat, beware the server-managed rich client!