In Case You missed it: Anti-buzz re-visited from October.
It’s something we joke about from time to time: Getting a new computer and marveling at how fast it seems, and yet in a few years time it will seem unreasonably slow. When we experience this we ask ourselves if it was the computer that changed, or was it our expectations? I put in some time explaining that, yes in fact, computers do get slower over time, but our expectations are certainly at work here as well. Sometimes, however, such a slow-down-over-time occurs because we move on to newer, bigger, more resource intensive software. While a desire to use newer software is somewhat an implication that your expectations are changing, you didn’t necessarily expect newer software to hog up more resources. Computers get better and better and yet the software we fill them with grows like goldfish, greedily taking up whatever space it is given.
This week’s topic is software bloat in its many forms. Software bloat can refer to a number of related phenomenon, but it should be noted that it does not refer to any legitimate use of extra resources. If the software is doing more powerful things, it should need a more powerful computer. Bloat is when the software gets slower and more resource hungry, without an equivalent user-experience.
It is easy enough to understand why software bloat was non-existent in the early days of computing. Computers had few resources and any software was necessarily resource efficient. For any particular application, computing eventually reaches a point where more resources than required are available and bloat becomes possible. But why does this happen?
Feature creep is the process by which unnecessary features are added to a product. Software is a competitive industry, and it can be dangerous to leave your product the same and simply hope it does well against other software with “new features.” Thus, the tendency toward an over-complicated feature set.
Broad User Bases
Consider any ‘bloated’ software you might be familiar with, including, possibly, your practice management suite. The burden of being a successful piece of software – and maintaining that market share – is that it must keep everybody happy. If you feel you only use a fraction of the features available in a software suite, consider that another group of users uses a different set of features. It is possible that every feature accounts for some of that broad user base.
Less apparent to non-engineers is that more modern development environments are streamlined for development – but at the cost of resource efficiency. The logic is that memory and processors are cheap, but an engineer’s time isn’t. Conveniences like interpreted languages and virtual environments make it faster to get a project done, but are not conducive to a resource efficient product. The push for fast development is again a matter of competition. With so many users and so many markets, there is a race to fill niche markets and a race to match features put out by the competition. Faster software development is tied very closely to software bloat.
To step back, the issue we’re discussing is that as we gain more and more computing resources, we keep asking what we can do with it. The fact that more and more software is going online has given software companies a new avenue of product research: instrumentation and user behavior tracking. The average user likely underestimates the benefits of mining user behavior to software companies. If an online marketplace notices that customers have to click four things to get a common task done, they will make the change to allow the user to do it in one. These nuances are only possible if every. single. action. is tracked. This sort of instrumentation is easier to implement on web-applications, but the trend in large software suites is to keep a log of user activity and ship it off to the software company at intervals. Has your software ever asked you to “help make the product better”? That’s what is going on; and it isn’t bad, and it /is/ helpful, but as more and more resources become available to us, our software is going to keep increasingly meticulous records of how it is used, and all that book-keeping ain’t free.
If interest in user behavior might be encouraging bloat for some time to come, there are forces that are discouraging to bloat. The first is easy to guess: mobile devices. Smaller devices turn the clock back on computing power and the old spirit of programming resource efficient solutions is alive in app-development. The second is a simple public backlash against over-complicated software. Given our recent discussion of Apple, it is fair enough to point out that Apple is credited with resiting bloat for the sake of design. Apple is the high profile example, (nor are they guiltless in matters of bloatware), but the trend toward simpler, faster software has some legs on all platforms.