Talk:Software bloat

Critics of bloatware frequently lay the blame for the rapid expansion of program size on the existence of the Microsoft Visual programming packages, especially Visual Basic and Visual C++.

I've removed this from the article; there's no corresponding reason why so its presence in the article is rather unsubstantiated

I didn't like it either, but felt I had to leave something of the rant that I found at first (I wrote most of the rest) Williamv1138 06:07, Oct 29, 2003 (UTC)

Heh, that's all right :) Dysprosia

The reference to ACDSee was removed for two reasons: 1. ACDSee 7 is faster than ACDSee 3. 2. There was a huge difference between ACDSee 6 and 3, most notably the addition of a more industrial grade database.

Software bloat doesn't mean the software in question never slims down, does it? It only needs to have a history of becoming "bloated". A-giau 20:21, 25 March 2006 (UTC)[reply]

In Why bloatware?, there is a statement in the 5th paragraph:

"... it is now the case that the lost revenue due to delaying time-to-market far exceeds the increase in revenue that almost any optimization can produce."

Sounds like an absolute to me. I mean, the gain depends widely on how bad the problem is and what kind of program it is. If you take a productivity application, optimizing it won't get you much revenue. On the flip side, if you ship a first person shooter without optimization, it could kill you; optimizing could make it the game of the year. --Astronouth7303 15:59, 18 July 2005 (UTC)[reply]

Am I the only one who thinks the article needs a huge revamp? Much of it seems pointless, and other parts a plain POV rant. I already edited the introduction paragraphs, but dared not touch the rest of it yet. --62.78.245.62 02:13, 26 July 2005 (UTC)[reply]

The phrase "This is not strictly true. Most distros, including those named above, offer a preset selection of packages that the developer perceives that the average user might need or want. While it is true that most Linux users will only use a small part of this selection, it is possible, even for a beginner, to modify this selection to better suit his or her needs. This software can also be removed or more added later during use." regarding Linux distributions was removed as it looked like a Usenet reply. This paragraph is replaced, however it reflects my very own view :) --212.174.145.126 14:27, 3 February 2006 (UTC)[reply]

To clarify, I'd mostly remove and/or heavily edit the middle part of the article which seems to just present a debatable hypothesis through rather twisted paths of logic, and present it as an absolute. I think this article could explore not only the historical background of the term as it does, but also the various angles of what makes up the image of a program being "bloated", and just what, if anything, makes "justification" or "unjustification". "Bloat" is only a descriptive term, after all, and a vague one at that. --62.78.245.62 05:59, 3 August 2005 (UTC)[reply]

"bloat" is present in other places too

I was thinking about this article and have thought that the issue of "bloat" is not unique to computer software vendors. It is characteristic of any large "one size fits all" vendor.

Consider a large electronic component supplier "Component Express/ComEx" (i.e. a company like DigiKey). ComEx stocks 500000 different products. Let's say (this is from the article) 80% of the customers only buy 20% of the products (for ComEx this would be more like 99% and 1% or more extreme than that, given the numbre of products stocked). But, just like Microsoft, or your favourite "bloatware" vendor, ComEx can't reduce their range because everybody might only want a very small selection of products but everybody wants different things. What good is it to you if they don't have the product you want? Nothing at all! And no amount of cost analysis or other accounting talk will reassure you.

A software example would be with Microsoft Word (not criticising Microsoft directly, it's the software I use). I have never used the "Double Underline" feature for text myself. So I could say it is a waste of resources to have a feature there I never use. But once again, Microsoft are not writing the software for just me, they're writing it for millions of others too.

Creeping featurism is a fact of life in software that is intended for wide scale sale to the public ("one size fits all"). This is due to various software issues that I will only go into on request. The real issue is how well "bloat" it is managed and implemented.

I'm sure you can think of many more examples of services you never use but still pay for, in your company, in the Government, etc. It's the same situation.

Thanks for Listening, El Barto

Code bloat merge suggestion

I'm not sure it is a good idea. Software bloat seems to be about at the application/system level, but code bloat at the intra-application and below level. --maru (talk) contribs 23:21, 19 April 2006 (UTC)[reply]

Agree: Merge While the two articles are not completely identical, I don't think they are disparate enough to justify two separate articles. I believe that both code bloat and software bloat are two different manifestations of the same phenomenon. Nigelquinine 19:21, 12 May 2006 (UTC)[reply]

Agree: Merge as well. Code bloat could result in Software Bloat but remember that it's not always the case. A smart compiler can optimize and cut a lot of the code bloat. / Kent (not a member)

Jump up and down in frustration: ~~I really don't care what happens~~ Don't merge I find that software bloat is the programme having an excess of features, whilst code bloat is the bad use of subroutines, resulting in high code redundancy (i think this page may be useful). Merge if you like, but there is quite a difference, so they may end up forking in the future. Actually, i seem to remember finding a problem on meta, where "free content" and "open content" were used interchangably, despite there being a huge difference. (i've forgotten how that's relevant though). See you all around . MichaelBillington 11:45, 10 July 2006 (UTC)[reply]

Disagree: Don't Merge: I agree with MichaelBillington. There's a small but fundamental difference between the two concepts. The article on Code bloat certainly needs some work but I don't think there'd be much improvement in merging the two articles together. In fact, I think it would be to the detriment of both as, like the example Michael raised, while the difference is small, it's quite significant. A program that suffers from "software bloat" may not have any "code bloat" and vice versa (I'm sure I can bloat "hello world" out to a few thousand lines if I really wanted to, without adding any features what-so-ever). Merging the two articles could potentially convey the wrong impression and further compound the problem (the problem of people not seeing the difference between the two). Until a formal decision is made though, I've added links to each article under "See also". Yay unto the Chicken 05:55, 11 July 2006 (UTC)[reply]

Disagree: Don't Merge: While the concept is similar, I disagree with Nigelquinine's characterisation: software bloat is driven by an excess of 'features' and functionalities (user pull), while code bloat is driven by limitations in the language, by programmer (in)competence (whether skill- or time-limited), or by needing to deal with extensive possibilities (coding push). Yay unto the Chicken's point about hello world is one side of the coin; it's also possible (though admittedly less likely) to have vast and overcomplicated functionality that is nevertheless written tersely and efficiently. Software bloat is most usually UI bloat, while code bloat is under-the-hood bloat; they're only different manifestations of the same phenomenon by virtue of the word bloat, and are entirely different things. They're linked; but while software bloat can be directly caused by code bloat, it can also be entirely its own. Software bloat when linked directly to resource hogging rather than features is driven by code bloat; where it's faster and easier not to write terse code but rather to get it out there fast, the algorithms will be ones that could be written fastest, with workarounds if necessary, rather than those that work best. But that's still code bloat. Perhaps we need to better clarify the difference between the two - the current first line of the page states that "Software bloat is a derogatory term used to describe the tendency of newer computer programs to use larger amounts of system resources (eg) than older programs". That's not all of software bloat though, unless followed up with the reasons those resources are used - such as more features or functionality, as mentioned earlier. As it stands, that definition leans fairly hard towards code bloat or even simply sloppy coding. Better wording there would clarify the difference between the two. --Firien § 11:23, 7 August 2006 (UTC)[reply]

Disagree: Don't Merge: As always with emerging language, there is a bit of confusion and overlap, but it could be better handled with a small paragraph in each article which clarifies the difference between the two terms. To my mind, Code Bloat is a term in the field of Computer Science, whereas Software Bloat is more of a socioeconomic phenomenon. Code Bloat has always existed where poor coding, feature creep, and poor design have let it exist. Software Bloat has become more (and perversely, less) of an issue where the exponential growth of processor power, hard disk capacity and low memory prices in the mid-nineties made software optimisation less economic for productivity software (the already cited example of entertainment software follows a different set of economic drivers). It is also incorrect to equate software bloat with inefficiency - one common optimisation is "loop unrolling", which usually bloats the resultant software package to gain a speed increase, and this is done quite deliberately and for good reasons. To summarise, software bloat will tend to increase over time until user expectations of timeliness create a negative market pressure. Code bloat will tend to decrease over time as programmer skill improves, until the optimal balance of code size/performance is met. To take a specific example, your word processor will underline spelling mistakes as you type when the programmer thinks that he or she can make that code fast enough on the target platform. If they can't make it fast enough, the program won't sell. If they can make it fast enough, but at the cost of requiring an unreasonable amount of memory or storage space, the program won't sell. IRSWalker 17:03, 6 September 2006 (UTC)[reply]

Disagree: Don't Merge: The code bloat is a more technical-related article, many readers unfamiliar with programming can understand the Software bloat article better (it has examples related to software and their use in general), and we could insert more code- and programming-related content in 'Code bloat'. --V. Szabolcs 15:59, 28 September 2006 (UTC)[reply]

Agree: Merge: (The discussion seems to have died out by now, but...) I believe that code bloat is a form of software bloat. Another form of software bloat is feature bloat, sometimes known as creeping featuritis. Currently there is not enough content in code bloat to justify its own article. If someone were to add more material and references to the code bloat article, perhaps it could be left there and some of it summarized here as well. In any event bloat is a huge problem with software. Bloated software consumes an inordinate amount (often many orders of magnitude more than is necessary) of all available computational resources such as time, storage space, and network bandwidth. This is not just wasteful in a theoretical sense, but it is wasteful in a true economic sense when the costs of electricity, air conditioning, rack space etc. are considered. Programmers (when trying to justify bloat) often say "memory's cheap" and "processing power is cheap", but that their time as a programmer is somehow especially valuable and expensive. -- 71.216.22.6 07:24, 26 January 2007 (UTC)[reply]

Wirth's Law

The unknown citation is perfectly known on Wikipedia : it is Wirth's law !
— Preceding unsigned comment added by 213.41.190.39 (talk • contribs) 10 September 2006 (UTC)

Quite true. Thanks. I've edited the article accordingly, moving the aphorism to the end of the "Background" section. CWC(talk) 06:50, 2 October 2006 (UTC)[reply]

Microsoft Windows

Isn't Windows, especially the later versions, an excellent example of bloatware? Shouldn't that somehow be mentioned in the article? Subversive element 12:51, 6 October 2006 (UTC)[reply]

I'm not sure I can agree, but if you have reputable references for what otherwise appears to be POV bashing, then feel free to get it written up and added. -- Mikeblas 00:13, 25 February 2007 (UTC)[reply]

And what source would you like? Why not look at windows itself. It is bloatware, by this wiki definition. But to state why (not being a source myself, just to give info) is as follows: Windows is an operating system designed to fill all available memory (your entire hard drive). It places archiving and system files through out the disk. It uses far more RAM then it should. I'm sure you could find a book about this, that would be less POV, though I'm not against windows, its what I use, its just the system itself has a lot of quirks. Zanduar 21:32, 18 July 2007 (UTC)[reply]

Definition

Software bloat is a derogatory term used to describe the tendency of newer computer programs to use larger amounts of system resources (mass storage space, processing power and/or RAM) than older programs. It is also used in a more general context to describe programs which appear to be using more system resources than necessary , or implementing extraneous features. Software exhibiting these tendencies is referred to as bloatware or, less commonly, fatware

Can somebody explain me the phrase necessary in the above definition.

Inefficient algorithms? Inefficient implementation? Bad design in general? There are many ways to make a program worse than necessary. --Gwern (contribs) 17:58 22 November 2006 (GMT)

A cry for help

User 203.49.223.69 (talk · contribs) left this plea on this page a couple of hours ago. I've refactored it for readability.

I find that dreamweaver is one example of "bloatware".

Sometime it manages to use up 100% CPU power from my AMD Athlon 64 3800 Processor

And all the unused RAM (Whats left over from 1gb when you minus all the normal programs)

Could someone offer some help at: inviterer@gmail.com

Thanks — Punksta — Tuesday, 20 February , 2007 at 9:37PM AEST (Australian Eastern Standard Time)

I've never used dreamweaver. Perhaps someone else can help Punksta? Cheers, CWC(talk) 12:48, 20 February 2007 (UTC)[reply]

Wikipedia isn't a tech help forum. Send him to Dreamweaver-specific fora. --Gwern (contribs) 21:16 20 February 2007 (GMT)

resource hog?

Why does "resource hog" redirect here? A resource hog is a program that uses a lot of resources -- perhaps even by design, in order to complete an intensive task -- which is a different concept than software bloat. -- Mikeblas 00:12, 25 February 2007 (UTC)[reply]

Disagree. Resource hog has connotations of greed and waste (from the 'hog' big; compare 'porkbarrel'). If a problem simply demands resources by its very nature, it's just a difficult problem. --Gwern (contribs) 01:14 25 February 2007 (GMT)

Even if I stipulate you're right, a "resource hog" in the context of software ends up being different than software bloat. A resource hog consumes any of several resources at runtime -- CPU time, memory, disk space, network bandwidth -- but software bloat only takes up code because it's the software itself, not anything else, that's bloated. The leading sentence of this article implies a resource hog and software bloat are the same thing, when they're really not. -- Mikeblas 01:30, 25 February 2007 (UTC)[reply]

I've removed references to "resource hog", then, as it's simply not the same as "software bloat". I think the terms are confused in this article at least partially because it is so poorly referenced; the piece at a point seems self-contradictory. I've liberally added {{fact}} tags to the article to mark the claims that I think need the most attention. -- Mikeblas 14:50, 12 March 2007 (UTC)[reply]

Someone edit this paragraph

I'd do it, but I'm not exactly sure what its trying to say (Unix is not my field). But I can tell its confused:

"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 and its receptiveness as a Free software project to extensions and additions. Until recently, the implementations was completely monolithic, and the user was forced to e.g install all drivers, when they would obviously need only a handful of them. Things were not better on the developer side, as a minor change required recompilation of the whole. Situation improved recently, as its main implementation by the X.Org Foundation went modular starting with X11R7.0. The X protocol itself remains criticized though."

-Gohst 00:38, 5 March 2007 (UTC)[reply]

This paragraph is really messy... its like a crazy fiddler. Okay it should be fixed now.Getonyourfeet 07:17, 6 March 2007 (UTC)[reply]

Examples

A good indication of software being bloatware is seeing the installation filesize increase dramatically from one version to the next:

Idea 4.5 (53 Mb) Idea 6.0 (66.2 Mb) http://www.jetbrains.com/idea/download/index.html

ICQ 98a (1.7 MB) ICQ 2000a (6.2 MB) http://www.oldversion.com/program.php?n=icq

Nero Burning ROM 3.0.2.0 (1.8 MB) Nero Ultra Edition 6.6.0.13 (33.0 MB) http://www.oldversion.com/program.php?n=nero

Macromedia Dreamweaver 3.0 (10.7 MB) Macromedia Dreamweaver MX (49.4 MB) http://www.oldversion.com/program.php?n=dreamweaver

ZoneAlarm 3.7 (3.7 MB) ZoneAlarm 6.5 (13.0 MB) http://www.oldversion.com/program.php?n=zalarm

Windows Vista is bloatware. That's why I'm still using XP. 84.110.211.107 10:55, 4 April 2007 (UTC)[reply]

Unfortunately it isn't as simple as measuring and comparing installation file size. "Bloat" is features that aren't necessary. When we compare installation sizes, we don't know if the added size is due to necessary features, or unnecessary features. We aslo don't know if the size is comprised of the software itself, or documentation; if the online help documentation trippled in size, certainly that would be beneficial, but it would also drive up the size of the installer image. I think your assertions are fundamentally flawed. -- Mikeblas 14:30, 4 April 2007 (UTC)[reply]

CRAPLETS

On 2007-04-05, Wall Street Journal, in Walter S. Mossberg's Personal Technology column, he talks about buying a new Windows computer. When he turns it on for the first time, he's bombarded by trial versions of software, icon-based ads, teaser programs, etc. He referred to these as craplets. —The preceding unsigned comment was added by 72.183.101.225 (talk) 13:36, 5 April 2007 (UTC).[reply]