software bloat(redirected from Feature bloat)
software bloat(jargon, abuse)
The result of adding new features to a program or system to the point where the benefit of the new features is outweighed by the extra resources consumed (RAM, disk space or performance) and complexity of use. Software bloat is an instance of Parkinson's Law: resource requirements expand to consume the resources available. Causes of software bloat include second-system effect and creeping featuritis. Commonly cited examples include Unix's "ls(1)" command, the X Window System, BSD, Missed'em-five, OS/2 and any Microsoft product.
software bloat(1) See bloatware.
(2) The ever-increasing complexity of software. Modern operating systems and applications are huge in size compared to software in personal computers in the late 1970s and early 1980s. They are gigantic next to software of the 1950s and 1960s.
There Are Several Reasons
Today's object-oriented programming languages generate much more machine language than earlier non-object languages. See object-oriented programming.
The increasing capacities of the computer's RAM and storage allow programmers to be much less concerned with conservation.
The marketing department demands more functions in the app to sell another version, even if 98% of people never need them.
In order to make it easier to write a program, software is often written in higher levels of abstraction. This eliminates the coding tedium but increases the number of instructions the computer must execute (see abstraction layer).
There are often too many cooks in the kitchen. The more software code is patched by different people, the more obtuse it can become. See Wirth's law and Freedman's law.
A Note from the Author
From 1963 to 1966, I programmed an IBM 1401 for the Pennsylvania Drivers License Division. The first widely used transistor-based computer, the 1401 processed all six million drivers in the state.
The machine had 12K characters of RAM (equivalent to 12,000 bytes). The driver master file was some 40 reels of magnetic tape.
The point of this story is that we never added the extra 4K memory module, upgrading the machine to its 16K maximum. It would have cost several thousand dollars, and we never found it necessary. Our programs, written in IBM assembly language, first on paper and then transcribed to punch cards, were extremely compact. We condensed program steps wherever we could.
There was no graphical interface, because there was no screen. We debugged our programs with memory dump printouts, and we didn't even have an operating system. What for? We just wrote our own input/output routines.
But, we processed an entire state!
Know anyone processing a state on a desktop computer with easily a million times as much RAM as we had in 1963? Software bloat. Better believe it. See IBM 1401.
|Looking Rather Nerdy in 1963|
|I'm the guy on the left clowning around with our IBM systems engineer. Love that tie!|
|In a Span of Twenty Five Years|
|The processing power in the 2016 MacBook (right) is nearly seven million times greater than Apple's PowerBook in 1991. Needless to say, we are not producing seven million times as much work on our personal computers today as we did 25 years ago. (Image courtesy of Apple Inc.)|