How did software end up bloated with so many unused features? Here's how
You've probably heard the phrase before: One man's junk is another man's treasure. Can the same be said of the features in some of today's full-bodied software?
When you consider the number features that are packed into an office suite like Microsoft Office or Corel Wordperfect Office and compare that to where software was back in the 1980s, the value proposition appears to be extraordinary. For less money than what a single application (eg: a word processor or spreadsheet) cost in 1987, not only do you get a much more feature-packed wordprocessor, you get an entire suite of software that feature for feature would have been valued around $4000-$5000 back in the old days. But just because today's feature-packed software is a great value proposition relative to what was available back then, does that mean we should take it? Or, does there come a point at which the extra functionality comes at both easy and difficult-to-quantify expenses involving extra acquisition cost, resource consumption and complexity. Particularly since the majority of users use 10 percent or less of the features (a widely accepted educated guess).
How did software get to this point? And could the shrink-wrapped software business end up collapsing under its own weight -- especially given the way on-line offerings allow users to take an a la carte approach where on-demand functionality is free or pay as you go?
One reason software is as bloated as it is today is because of the reviews wars of the 90s. So bad were those reviews wars that, when I was of running one of the reviews labs at Ziff Davis, we watched as software vendors added scores of new features to their solutions before ever polishing (or worse yet, debugging) the old ones.
I'm sure the product managers of those days would be happy to argue with me, but I can guarantee you that many of the new features (what today, equates to bloat) were not put there because customers were screaming for them. All an influential product reviewer at a place like PC Magazine, PC Week, InfoWorld, or PC World had to say during some confidential product roadmap meeting was, "You know what would be really cool? If you did XYZ." Magically, XYX feature would appear in the next beta version of the product and subsequently, the influential reviewer would write glowingly of both the feature and the product. Internally, vendors would refer to these features as the "John Smith feature" (where "John Smith" is the name of the influential reviewer) and would even tell the reviewer about how the new feature had that internal nickname. Egos were heavily stroked (guilty). Reviews wars were won (guilty). Products ended up with a bunch of features that almost no one used (not even the reviewer).
The reviews wars essentially produced a race to bloat and complexity. So palpable was that race-like feeling between companies such as Wordperfect (later acquired by Novell, with most assets eventually flowing to Corel), Borland (remember Quattro Pro), Microsoft, and Lotus (eventually swallowed by IBM) that when it came time to test products, orchestrating an apples to apples comparison was impossible.
Not only did the coagulation of office suites take the problem to an entirely new level, the number of new features being rolled out while old bugs and other problems persisted ramped up as well.
Today, I'm not sure shrink-wrapped software vendors have a real clue as to what customers are using and what they aren't. Unlike a software as a service (SaaS) provider like Google with Google Apps who can monitor with exacting precision what features get used by way of the Web pages and APIs being accessed, shrink wrap software vendors must resort to educated guesses and projections based on indirect data like support calls. One thing is for sure: I can't remember a meeting about the next big version of some ten year old product where the vendor led with "In this version, we removed about 50 percent of the features." One problem with "bloatware" is that once a few customers start to use a feature, it's literally impossible to take it out without getting crucified in the press for being insensitive to the backwards compatibility issue.
Interestingly enough, even though SaaS providers like Google can break their core services down into simpler, discreet, and on-demand components (with boutique features -- the ones that in the shrink-wrapped world, amassed into bloat -- being offered through on-demand software widgets that can be easily snapped in and out), history is already repeating itself.
Between Google's anticipated launch of a presentations offering in the Summer (based on its acquisition of Tonic Systems) and the addition of charting to its existing browser-based spreadsheet, Google is already piling on new features before adding some much needed polish to the old ones. In my post about why there's much more to Google Office [sic] than meets the casual observer's eye (when it's run in the context of the private partitions or "domains" that Google offers to businesses, organizations, and families), I discuss some of the shortcomings to this special "business context" of Google Apps (the real name of Google Office).
But there are others. For example, relative to how most spreadsheets and calendaring software work, Google Sreadsheets and Google Calendar leave much to be desired when it comes to printing. So lacking in flexibility are the printing features (for example, printing a detail view from Google Calendar or specific ranges in Google Spreadsheets) that the only choice users may have is to export to whatever shrink-wrapped software they currently have (which may not always work which was the case with my Google Calendar and Outlook).
Of course, this brings us back to the one man's junk is another man's treasure syndrome. Just because I need an easy way to print out my appointment details over a user defined date range doesn't mean everyone that uses Google Calendar will need the same thing. It could be a treasure to me, but junk to everyone else, and ultimately bloat to Google Calendar. Likewise, whereas I have no need for the charting feature that Google just added to its Spreadsheet service, there are probably many other users for whom such a charting features was the gating factor to their use of Google Apps.
Today, Google has a ways to go before Google Apps are ready for business primetime. The to do list isn't too long, but there's work to be done. In addition to cleaning up printing, Google needs to harmonize HTML publishing across it's Web hosting, Start Page (to me, the beginnings of a Google-hosted Virtual Private Intranet or "VPI") and Google Docs in a way that it's essentially one tool governed by a common interface with access to different templates but the same widgets. There's more (I'll be publishing what I think the list is soon). That to do list will probably require enough cat herding and executive intervention at Google that it could be another year before even a handful (let alone the whole portfolio) of business-applicable services begins to hang together really well in a business or organizational usage context.
While that year or two years or whatever it takes passes, companies whose offerings and business models are tied to incredibly bloated, shrink-wrapped software (like Microsoft and Corel) have an opportunity to recalibrate. Wordperfect Lightning is exactly the sort of recalibration I'm talking about. But the clock is ticking and ticking fast (some don't agree on the basis of the off-line problem, but Zimbra just proved it can be addressed and Google won't be far behind). And, while the architecture and availability to any client platform (browsers need only apply) are some of the key disruptions that something like a Google Office brings to the status quo, the biggest disruption of all will be cost.
Today, Google offers a bundle that includes word processing, spreadsheet, (with presentations about to be added), HTML publishing, lightweight portal creation (the Start Page), e-mail, calendaring, instant messaging, VoIP, and Web hosting -- all of which work surprisingly well together (and are also surprisingly easily administered) when contextually offered through Google's business-oriented domain context -- for absolutely no cost per user. For an extra $50 per user per year (chicken feed), mailbox capacity per user is bumped to 10GB, you get 24/7 telephone support, and a guarantee of 99.9 percent uptime. Where Google Apps has some glaring omissions (eg: e-mail archival, backup, and recovery for the purposes of compliance), the $50 per user per year charge also means that third party-provided apps for filling-in those gaps can be snapped in. Postini for example offers a variety of add-ons starting at a very reasonable $9.95 per user per year to users of the Premier Edition of Google Apps.
Whether Google's core base of functionality is all you need, or you want to add Postini-like components in a la carte fashion, my bet is that once organizations start to realize how disruptive Google's model can be to their total cost of ownership (including everything from ease of administration to hard dollar costs), we'll get to see a sea change the likes of which we haven't seen since about 1981.