Talk:Software bloat

From Wikipedia, the free encyclopedia

You have new messages (last change).
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)

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)

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)

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)

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)

Contents

[edit] "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


[edit] 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)

  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)

[edit] Wirth's Law

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

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)

[edit] 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)

[edit] 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)
Retrieved from "http://en.wikipedia.org../../../s/o/f/Talk%7ESoftware_bloat_36cd.html"