Once upon a time, back in grandfather days, it used to be that a new software release was an occasion for rejoicing. A new version number indicated a complete rewrite of every last line of code, from scratch. You savored the long-awaited, much-improved functionality that came with the new release, and you knew that there wouldn't be a new version for some time. Vendors typically put more attention into maintenance than upgrades, so a stable version could stay stable for as much as five years. You could actually install a software package and still be using it, happily, years later.
Oh, how times have changed.
I don't know exactly where it started, but somewhere along the way software vendors started prioritizing upgrades over maintenance. They moved new versions out faster and faster, and eventually version releases seemed to replace maintenance as the standard of care for software packages. In fact, some vendors now include the year as part of each new version number -- a clear acknowledgment that the company plans to release a new version at least once a year.
The problem is, a year isn't long enough to seriously rework a project. It's enough time to bolt on some bells and whistles, but not to fix any serious problems in the code. A personal finance package I once used had a data corruption bug that showed up in 1998. Even though the package went through numerous version changes and lots of new features were added, it was widely reported that the bug was still there in 2002. I eventually switched to a different program; one that was able to figure out my data file and rebalance my accounts. Fascinating as it was to be able to set up a button bar of commonly used tasks, it was more important to me that I be able to get a straight answer to the simple question, "How much money is in my bank account?"
Unfortunately, the upgrade frenzy seems to have its origins in accounting rather than quality control. It's a generally accepted policy that minor updates are free and major ones cost money. Need more money? Put out a major version release. With time, companies have become more and more dependent on the money produced by such releases, and less and less scrupulous about the actual product behind the shiny new numbers.
To a certain extent, of course, users can simply ignore the numbers game. After all, you don't have to upgrade every time a new version comes out. Most of people are satisfied with the version they know, and not all that impressed by the bells and whistles that come with annual updates. But every user who fails to upgrade represents loss of cash flow from an accounting perspective, so vendors have found another way to make their new versions indispensable.
Planned obsolescence is, of course, a vendor strategy to ensure that a given software version becomes obsolete within a particular time frame. One example of planned obsolescence is a vendor's failure to produce bug fixes -- even mission-critical ones -- for any version but the most recent one. Another typical example is file incompatibility between product versions. According to this strategy, a new version of a word processor should not, by default, save files readable by old versions. For best results, it should give dire warnings when trying to save old versions. And for the icing on the cake, the "old version" save should be marginally incompatible with the new one, such that a file that has been moved between the two versions no longer looks right, no matter how the user tries to repair it.
It's easy to see how planned obsolescence works together with the network effect to the vendor's advantage. If only the newest version of a software package is for sale, users have to buy it for their newer systems. And if old and new versions are incompatible, then anyone who wants to exchange documents with a user on a new system has to upgrade. It's diabolical.
Unfortunately, this strategy isn't limited to word processing software. A while back, I had to upgrade an otherwise perfectly functional compression program in order to read archives created by a newer version. And while most companies won't push too hard to make you upgrade your operating system (because the backlash can be painful), users know that an OS upgrade, when it comes, usually demands a complete system overhaul. Most software programs these days won't run on a new OS version without a patch; and most patches are meant to work for only one or two versions.
It gets worse. You might think that the bells and whistles requirement would imply some kind of increased functionality, but, in fact, it often means the exact opposite. Most people don't remember anymore, but Norton Utilities once came with a really good disk editing utility. It allowed you to poke around at the raw contents of files, or even just raw disk data, by hand. If it's still there, I can find no trace of it on Windows or Mac. That was the feature I used most often in 1997; today, I have to rely on other programs instead.
Often, the loss of functionality is the result of a company's change of focus. For instance, the tech-savvy geek market isn't very big, so Norton Utilities has, over the years, become more of a product for users. A popular video game series started out as a fairly carefully done simulator of a very complicated war game; but over time, it's turned into a first-person shooter, with most of the complexities and subtleties of the war game thrown out. While the change likely reflects the market, it's sort of a disappointment for the people who really liked the elaborate and complicated game.
The most famous example of this in recent memory is probably Windows ME, with which Microsoft removed almost every trace of support for running in DOS mode. As a result, millions of users are still using Windows 98 -- and demanding support for it -- because it was the last version to support certain legacy applications. A decade from now users will still be demanding emulators that can run Windows 98, but no one will be asking the same for Windows ME. In this case, the loss of functionality was too significant for many users.
For most users, getting off the upgrade treadmill is an unattainable goal. As a professional writer, I have to be able to read and write documents in a bewildering variety of formats. I have to stay current with perhaps a half-dozen software packages across two or three platforms, and the people I work with are generally in the same boat. Expecting file compatibility across different platforms isn't a good bet right now. Even StarOffice -- once touted as the alternative to Microsoft's proprietary whims -- regularly mangles documents that were written for a format other than its own. On the other hand, that I can read them at all is progress of a sort.
Unfortunately for most people, the solution to the upgrade treadmill lies with vendors. For vendors, the current trend is to value immediate, upgrade-driven profits over customer loyalty. But that could change, especially with more discerning users. Frequent, useless upgrades have driven me away from a number of otherwise excellent applications. As a result, I've begun to look for certain signs that indicate that a vendor is more interested in draining my wallet than improving its product.
If, for example, a new version comes out while the old one still has critical show-stopper bugs, such as regular or frequent crashes, I am much less likely to buy the new version -- regardless of my investment in the product. I have more than once jumped ship from a several-hundred-dollar investment in a given package because I lost faith in the company behind it. Providing a genuinely workable patch to the previous version would give me a choice of whether or not to buy the new version, based on its features rather than on the unacceptability of the existing product. A company that did that would be taking a risk, particularly in the short term; but I'd be more likely to buy its product in the long term.
I'm not the first person to write about the upgrade treadmill. I won't be the last, and next year's article won't even really be any better. As long as programmers and companies offer poorly planned and executed upgrades instead of real fixes and improvements, you'll still be charged extra money for newer versions that don't really improve anything. As users, all you can do is try to get away from products with this lifecycle. Some vendors still take the time to improve their products before they ask for more money, so support them. If nothing else, try to avoid products that introduce intentional incompatibilities. These only add insult to injury.
This week's action item: Ask a vendor about availability of a patch for an old version of a package -- say, one you bought within the last couple of months.
- Read what the author said about the unacceptability of frequent software crashes in
last month's column, "Crashes, bugs, and workarounds -- developers must do better"
(developerWorks, August 2004).
- Learn more about the thinking behind Sun's StarOffice, with Claude Bauer's
introduction to "Sun's open, componentized OpenOffice productivity suite" (developerWorks, February 2001).
- Discover whether Zack Urlocker's take on
"The upgrade treadmill" (Valley of the Geeks, July 2000) is as funny today as it was four years ago.
- Join David Berlind as he spotlights Lotus Notes to analyze the pitfalls of the upgrade treadmill for vendors, as well as users (ZDNet, March 2002).
- Explore the user perspective on StarOffice as a solution to Windows in Chris Halsall's Step off the Upgrade Treadmill (Business Examiner, September 2000).
- Find articles about every aspect of building for the World Wide Web in the developerWorks Web Architecture zone.
- Browse for books on these and other technical topics.
Peter Seebach is a freelance writer who's participated in the e-business game for years and just wants everyone to play fair. If you have comments, feel free to contact him at crankyuser@seebs. plethora.net.
Table of contents
Tags
Use the slider bar to see more or fewer tags.
For articles in technology zones (such as Java technology, Linux, Open source, XML), Popular tags shows the top tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), Popular tags shows the top tags for just that product zone.
For articles in technology zones (such as Java technology, Linux, Open source, XML), My tags shows your tags for all technology zones. For articles in product zones (such as Info Mgmt, Rational, WebSphere), My tags shows your tags for just that product zone.
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags