Software bloat
From Wikipedia, the free encyclopedia
Software bloat (or resource hog) is a term used in both a neutral and disparaging sense, to describe the tendency of newer computer programs to be larger, or to use larger amounts of system resources (mass storage space, processing power or memory) than older versions of the same programs, without concomitant benefits being provided to end users.
Bloat is ascribed to various causes including: the tendency to replace efficient focussed applications with less efficient enhanced versions, inefficiencies or unnecessary modules in program design and operation, and the incorporation of extended features which will be extraneous or low value for most users but slow down the program overall even if unused.
The latter is often blamed either on the prioritisation of marketing and "headline feature-set" over quality and focus, or the need to be perceived as adding new functionality in the software market, which for many products relies upon the existance of regular enhanced versions to be sold within the existing user base.
It is also used more generally to describe programs which appear to be using more system resources than necessary. Software exhibiting these tendencies is referred to as bloatware or, less commonly, fatware.
Contents |
[edit] Background
Software developers involved in the industry during the 1970s had severe limitations on disk space and memory. Every byte and clock cycle counted, and much work went into fitting the programs into available resources. The extra time spent by programmers translated directly into smaller, more efficient software products, and hence was seen to translate directly into sales revenue.
This situation has now reversed. Resources are perceived as cheap, and rapidity of coding and headline features for marketing are seen as priorities.[citation needed] In part this is because technological advances have since multiplied processing capacity and storage density by orders of magnitude, while reducing the relative costs by similar orders of magnitude (see Moore's Law). Additionally, the spread of computers through all levels of business and home life has produced a software industry many times larger than it was in the 1970s.
Finally software development tools and approaches often result in changes throughout a program to accommodate each feature, leading to a large scale inclusion of code which affects the main operation of the software, and is required in order to support functions that themselves may be only rarely used. In particular, the advances in resources available has led to tools which allow easiest development of code, with less priority given to end efficiency.
Niklaus Wirth has summed up the situation in Wirth's Law:
- Software becomes slower faster than hardware becomes faster.
[edit] Possible causes
Some of the observed bloat is caused simply by the addition of new features and content, such as templates, or by the use of higher-level programming languages. However, at other times the cause may be a programmer's lack of attention to optimization or design, often frowned upon by other programmers as a sign of carelessness, laziness, or lack of skill. As a result, the emphasis in software design could be argued to have shifted away from tightness of design, algorithms and resource usage. Instead, time-to-market may be seen as becoming the key focus of developers.
The extra time needed to optimize software delays time-to-market, losing some potential sales and increasing labor costs. The improvement in quality due to optimization was previously thought to more than make up for these costs, but with modern hardware, it is now more common that the payoff from optimization is too small to justify it, or at least is seen as too small.
The software industry has responded to this changing trade off by emphasizing rapid code development, automating programming tasks that had previously been areas of fine craftsmanship, and re-automating on top of that. The result is multiple layers of software abstraction resting on top of each other, and the task of the modern software programmer often consists more of administering automatic code generators and pre-written components to their will than in the fine handling of software to be completely optimized - though, with the establishment of well-founded, stable, optimized and dependable software toolkits, this enables functional code to be created much faster and more powerful than coding up equivalents by hand, where development time would be significantly longer. A case in point is NeXT's OpenStep Foundation Kit and Application Kit - a set of reusable objects that enabled developers to create functional and usable code faster than conventional methods.
Since any single application is usually small enough to fit on any computer's hard disk or RAM, developers usually do not consider size implications for users, who often install many bloated products.
Some hold that the result of modern rapid application development practices, forgoing the optimization practices of the past, is that modern software running on faster computers does not appear to be significantly faster, this is due to the consumption of underlying technical advances by layers of software abstraction in pursuit of time-to-market [citation needed]. Unfortunately the abolition of this software abstraction can hamper the underlying development of the program. Software structures that are well crafted in place to allow for easy extensibility and maintenance will assist software developers in that upgrading existing code will be simpler and faster.
However, the optimization at the machine-code level need not be done by hand. Modern compilers often take optimization of code into consideration, and this forgoes the need for hand-manipulation of assembly code. Naturally, this software optimization is never one-hundred percent perfect, but then the resulting effect from a programmer making the optimized code fully optimized is negligible.
A further factor is that programmers tend to develop and test their programs on the biggest, fastest computers they can get their hands on and tend to optimize for speed only while there is a perceived lack of it, while most users' computers will be years older with a fraction of the space and speed. Thus, unless efficiency is a specific goal, software tends to tailor itself to fit the dimensions of the most recent computers available to software developers. This is most true in the commercial sector where companies supply their programmers with the fastest computers they can, thinking to make them more productive.
The more cynical observer may remark that commercial products need to add more bloat with each version in order to sell those new versions to potential customers. Even greater cynics might also comment that any tie between commercial software houses and hardware corporations may result in the need to make sure that even the latest desktop PC will slow significantly when running their applications; thus creating the ever present need for buying new hardware.
[edit] Reasons for existence
Why is there so much bloatware around?
In his essay Strategy Letter IV: Bloatware and the 80/20 Myth,[1] Joel Spolsky argues that while 80% of the users only use 20% of the features (a variant on the Pareto principle), each one uses different features. Thus, "lite" software editions turn out to be useless for most, as they miss that one or two special features that are present in the "bloated" version. Spolsky sums the article with a quote by Jamie Zawinski:
"Convenient though it would be if it were true, Mozilla is not big because it's full of useless crap. Mozilla is big because your needs are big. Your needs are big because the Internet is big. There are lots of small, lean web browsers out there that, incidentally, do almost nothing useful. But being a shining jewel of perfection was not a goal when we wrote Mozilla."
[edit] Examples
A common example of software bloat is the evolution of word processing programs, which have for long been deemed especially resource-hungry in the range of typical productivity applications. It can be argued that the basic tasks — writing and simple type-setting — have been possible since the first such programs were introduced around 1970, and that more advanced features bring needless weight to those who rarely need them. On the other hand, users have since grown used to modern convenience features, and less feature-packed applications are still available for those who prefer them.
Drivers are also a major source of bloat, which occurs when hardware manufacturers add functions that are not usually needed. A good example would be some printer/Digital camera drivers, which can include rarely used functions like photo editing which can consume in excess of hundreds of megabytes.
In the second half of the 1990s and early 2000s, Java was the platform of choice for bloatware. Client-side scripting techniques were not mature and most web applications chose implementing small user interface features, such as a tree view, in Java, which requires a massive virtual machine to load. Moreover, some early Java applications required a specific virtual machine (namely Microsoft's implementation), which was only available at a specific hardware platform, rendering Java-ization meaningless. Advancements in virtual machines and developer's preferences on more native ways of implementing web-based UI features such as Javascript greatly reduced this Java-related bloatware feel.
The X Window System, which is the most commonly-used windowing system for flavors of Unix, is a classic example of bloatware, partly due to its age.
The term bloatware can also refer to distribution or installation programs that install a considerable number of unnecessary programs and consequently can have a negative effect on the operating system's stability or speed.
