Lecture
Bloated software (also known as bloatware, fatware, elephantware) is software that consumes an excessive amount of system resources — including RAM, processor time and disk space — without providing meaningful benefit to the user. Such software is often overloaded with unnecessary features, poorly optimized, or preinstalled by device manufacturers with no easy way to remove it; it also tends to carry far too many extra features that consume a disproportionate share of system resources, especially when those features are unneeded or of little use to the program’s actual purpose (such features are often called «gimmicks» or «bells and whistles»).
The English term bloatware (also crapware, shovelware) has a second meaning as well, referring to resource-hungry preinstalled software that the user does not need but which is forced upon them by the manufacturers of computers, tablets, smartphones and so on.
The main difference between builders and programmers is that builders know when to lay the last brick, while programmers do not. Every new version of a program adds something to the old one. The «Tower of Babel» grows by leaps and bounds, and at some point it begins to fall.
Every program will expand until it can read mail. Programs that cannot expand that far are replaced by ones that can.
Technically, bloated software is most often associated with the notion of «feature creep», also called «creeping featurism/featuritis», which describes the tendency of developers to add more and more capabilities to a software product in an attempt to «keep up with the competition», yet which in practice results in a slower and less efficient product. According to research data published in 2002, only 20–25 % of the features in software products were used always or often, while as much as 45 % of features were never used at all. In Martin Fowler’s opinion, most projects ought to be only a quarter of their current size.
Bloat affects more than just program performance: as the volume of code grows, so do the costs of maintaining and developing it. On top of that, poorly designed extra features can become a source of vulnerabilities.
Another contributor to «feature creep» is the «second-system effect», described by Frederick Brooks as far back as 1975: a programmer developing their second system tends to add all the capabilities they were unable to include in the first one (for lack of time), so the second system often ends up overloaded with features.
Software developers who worked in the industry in the 1970s faced severe constraints on computing power, disk space and memory. Every byte and every clock cycle counted, and a great deal of effort went into squeezing programs into the available resources. Achieving that efficiency was one of programmers’ highest values, and the best programs were often called «elegant», a term used by mathematicians to describe a proof that is neat, economical and powerful.
By the 21st century the situation had reversed. Resources were seen as cheap, while coding speed and headline features for marketing were treated as priorities. This is partly because technological advances have since increased computing power and storage density by orders of magnitude, while cutting relative costs by comparable orders of magnitude (see Moore’s law). In addition, the spread of computers throughout every level of business and home life has made the software industry many times larger than it was in the 1970s. Programs are now typically churned out by teams directed by committees in software development studios (also known as software houses or software factories), where each programmer works on only a portion of the whole — one or several subroutines.
Finally, software development tools and approaches often lead to changes across the whole program to accommodate each feature, resulting in the large-scale inclusion of code that affects the software’s core operation and is required to support features that may themselves be used only occasionally. In particular, the growth in available resources has produced tools that make code development easier, again with lower priority given to the end result’s efficiency.
Another cause of bloat is independently competing standards and products, which can create demand for integration. There are now more operating systems, browsers, protocols and storage formats than there used to be, which bloats programs because of compatibility issues. For example, a program that once could save only in text format must now save in HTML, XML, XLS, CSV, PDF, DOC and other formats.
Niklaus Wirth summed up the situation in Wirth’s law, which states that software slows down faster than hardware speeds up.
In his 2001 essay «Strategy Letter IV: Bloatware and the 80/20 Myth», Joel Spolsky argues that although 80 % of users use only 20 % of the features (a variation on the Pareto principle), each of them uses a different set of features. As a result, «lightweight» versions of software turn out to be useless to most people, because they lack the one or two specific features that are present in the «bloated» version. Spolsky closes the article with a quotation from Jamie Zawinski referring to the Mozilla Application Suite (which later became SeaMonkey):
«Convenient as 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».
Software bloat may also be a symptom of the second-system effect described by Fred Brooks in «The Mythical Man-Month».
Preinstalled software (OEM bloatware):
User-installed software:
System software:
Enterprise software:
In 1996 Niklaus Wirth wrote the article «A Plea for Lean Software», raising the problem of programs whose growth in resource requirements outpaces the growth of their functionality and performance. He borrowed the term «fatware» from a 1993 article in Byte magazine.
Wirth pointed to two tongue-in-cheek «laws» that nonetheless accurately reflect the situation:
Two factors contribute to consumers’ acceptance of ever-growing software: rapidly increasing hardware performance, and disregard for the fundamental difference between vitally important capabilities and those that would merely be «nice to have».
Nathan Myhrvold used the phrase «software is a gas» to describe the following phenomenon: no matter how much hardware improves, developers always tend to add functionality until their programs run up against the limits of that performance.
Adapting old programs to new machines usually means making changes that cause the new machines to work like the old ones.
Users generally take a negative view of bloated software. In Joel Spolsky’s opinion, they do so for no good reason, for the following reasons:
| Windows version | Processor | Memory | Disk footprint |
|---|---|---|---|
| Windows 95[16] | 25 MHz | 4 MB | ~50 MB |
| Windows 98[17] | 66 MHz | 16 MB | ~200 MB |
| Windows 2000[18] | 133 MHz | 32 MB | 650 MB |
| Windows XP[19] (2001) | 233 MHz | 64 MB | 1.5 GB |
| Windows Vista[20] (2007) | 800 MHz | 512 MB | 15 GB |
| Windows 7[21] (2009) | 1 GHz | 1 GB | 16 GB |
| Windows 8[22] (2012) | 1 GHz | 1 GB | 16 GB |
| Windows 10[23] (2015) | 1 GHz | 1 GB | 16 GB |
| Windows 11[24] (2021) | 1 GHz | 4 GB | 64 GB |
In 2008 the site Switched Downloadsquad published examples of the worst programs in the «elephantware» category, that is, «bloated programs that make the newest personal computers boot like a Pentium 2 with 64 MB of RAM». The following programs were named:
A good example illustrating the growth of requirements is the system requirements for installing Microsoft’s operating systems. As can be seen, that growth was clearly disproportionate to the appearance of new capabilities. It should be borne in mind, however, that this is partly explained by the «trimming» of Windows features depending on the licence, while the core system files remain the same in number. The minimum requirements for Windows 10 stayed the same as for Windows 7, even though users and testers report an actual increase in memory consumption. Consequently, keeping the minimum requirements unchanged is to a known extent a marketing move.
Nero Burning ROM is often cited as an example of unjustified bloat. Over its life cycle, the package acquired a graphics editor and a sound editor, audio and video players, and an alternative version of the burning program with a simplified interface — all of it wrapped in a special launcher shell and given elaborate graphical visual styles.
Software bloat can lead to a greater number of vulnerabilities, because of the increased difficulty of managing a large body of code and dependencies. It can also make it harder for software developers to understand the code they ship, increasing the difficulty of finding and fixing vulnerabilities.
Although bloatware is not a form of malware and is not intended for malicious purposes, it can unintentionally create certain vulnerabilities and increase the risk of the user’s computer being infected with computer viruses or ransomware.
The direct opposite of bloat is the KISS principle, which forbids complicating systems that already work well. The first principle of the Unix philosophy is likewise aimed against bloat.
In 2014 South Korea passed legislation requiring smartphone software developers to provide a way to forcibly remove unwanted bloated software («unnecessary pre-installed bloatware»). This step was prompted by the increasingly common practice of preinstalling unnecessary, resource-hungry software on smartphones that could not be removed by standard means.
Comments