What are the causes that lead to an overbloated software?

Question

Today I decided to perform a clean install for Creative Sound Blaster drivers, as they always start glitching all by themselves after some time. And that meant I had to go through the whole cleanup procedure. And that took me almost 2 hours..

And honestly, I can't see a reason why?! And although Creative, IMHO, is an absolute 1st place winner for producing poor quality software that never works, the bloat problem is not exclusive to them.

PC with Canon digital camera driver will have around 10 Canon entries that are interconnected with all sorts of connections. Visual Studio is also a prime example, there is around 50 or so entries for full install, and repairing that thing is only possible with complete nuking. And once it even managed to ruin the whole OS install when I was upgrading from VS2k8 to VS2k8SP1 or something. As it turns out 5GB of free space was not enough for 300Mb patch...

So this really seem to be a widespread problem. Almost every application nowadays usually contains unpackers, multiple spywarish "friends" that are installed, drivers are usually around 600Mb for everything including printers and so on.

But why? Is it developer fault? Applications like that are nightmare to support, they never work 100% nowadays, and almost all users I know are very negative about all that bloat they get as a mandatory driver install for USB thumb drive/Printer/Camera/Sound Card/Browser.

It seems that NSIS from Nullsoft is the only clean setup system that is not bloated, from what I know, for example, Firefox install. Clean, pretty much xcopy based install without any problems.

So why people are not using simple setups and applications that are not rooted over 30 layers of interconnection? Is it because developers are lazy? Use of codegen tools? Is it because corporations force heavyweight apps as something users will love? What's the cause, and is there a hope software will return back to basics someday? What are the steps to avoid writing bloat when you start new application from scratch?

Feature creep. No new features, nothing for the developers to do. — Robert Harvey, Dec 11 '11 at 15:36
When you say there are "50 or so entries", what do you mean? Entries in what? — Bryan Oakley, Dec 11 '11 at 19:56
"absolute 1st place winner for producing poor quality software that never works" -- Obviously you've never used Samsung Kies ;-) — Dean Harding, Dec 12 '11 at 09:21
Same causes that lead to a messy kitchen: increasing entropy. It takes a lot of focus and energy to keep things organized. Chances are that some extra change will create more chaos than more order. — Job, Dec 12 '11 at 20:35
This question doesn't seem to be about bloat, but rather about problems with installing and uninstalling software. — David Thornley, Dec 12 '11 at 20:53
SQLServer 2008R2 is the worst. Once badly installed, you *cannot* remove it without a full OS reinstall. (well you can, but trust me, a full OS reinstall is significantly quicker and easier) — gbjbaanb, Jul 07 '14 at 07:48
Also poor testing (QA) or lack of emphasis on certain qualities of the software (e.g. speed, size, efficiency). Totally enterprise-class minimum viable product. — rwong, Jul 07 '14 at 08:54
There might be some non-scientific, non-logical yet legitimate reasons why they want a purposely bloated version of an algorithm or a piece of software. I have learned to not judge management as they may know what we do not know and do not want to know. — InformedA, Jul 07 '14 at 10:15

score 10 · Answer 1 · edited Jun 16 '20 at 10:01

10

To quote Joel in Strategy Letter IV: Bloatware and the 80/20 Myth:

[...] there are lots of great reasons for bloatware. For one, if programmers don't have to worry about how large their code is, they can ship it sooner. [...] If your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible. [...] But the loss to you of waiting an extra two months for the new version is perceptible, and the loss to the software company that has to give up two months of sales is even worse.

A lot of software developers are seduced by the old "80/20" rule. It seems to make a lot of sense: 80% of the people use 20% of the features. So you convince yourself that you only need to implement 20% of the features, and you can still sell 80% as many copies.

Unfortunately, it's never the same 20%. Everybody uses a different set of features. [...]

When you start marketing your "lite" product, and you tell people, "hey, it's lite, only 1MB," they tend to be very happy, then they ask you if it has their crucial feature, and it doesn't, so they don't buy your product.

edited Jun 16 '20 at 10:01

Community

1

answered Dec 11 '11 at 18:18

Péter Török

46,427
16
160
185

It is one thing "if programmers don't have to worry about how large their code is" when writing only the necessary and right code, and a very different thing having programmers carelessly write and add code which will unnecessarily increase the size of a program just for the sake of shipping sooner. But code size is NOT really the problem; the problem is that most if not all bloated programs are inefficient, slow, buggy, unreliable, frequently crash, cause a lot of inconveniences and frustrations to users, or cause fatalities. Bloatware is bad. Want to ship sooner? Write lean programs. – Only You Jan 11 '14 at 19:52
Talking perceptibility, benefits and improvements? "If your software vendor stops, before shipping, and spends two months squeezing the code down to make it 50% smaller, the net benefit to you is going to be imperceptible." Obviously, we want to avoid that, specially when there's no critical or important necessity. – Only You Jan 11 '14 at 20:20
But we also want to avoid this: "Software bloat is a process whereby successive versions of a computer program become perceptibly slower, use more memory/diskspace or processing power, or have higher hardware requirements than the previous version whilst making only dubious user-perceptible improvements." Size for the sake of size is not good either. Making a big program smaller does not necessarily make it better or more efficient. Again the important goal should be program efficiency irrespective of program size. http://en.wikipedia.org/wiki/Software_bloat – Only You Jan 11 '14 at 20:21
1

Lean development can be summarized by seven principles: 1 Eliminate waste 2 Amplify learning 3 Decide as late as possible 4 Deliver as fast as possible 5 Empower the team 6 Build integrity in 7 See the whole http://en.wikipedia.org/wiki/Lean_software_development – Only You Jan 11 '14 at 20:22

score 4 · Answer 2 · answered Dec 12 '11 at 09:12

Quite a large part of it is to do with dependencies of a product. Your operating system ships with a lot of standard libraries for all kinds of things. However, these standard libraries have different versions throughout the evolution of the OS, and any generic installer cannot assume that the specific version it was built against will actually be present on the OS.

Therefore the full installer will need to include the correct version of every dependency to make sure that everything will definitely work after installation, no matter what the initial state of each dependency on the target computer. This can be quite a significant bloat for certain types of applications, for example .NET-based applications that need to be deployed to Windows XP systems.

Until recently, one installer system that I worked with needed every single previous .NET version to be installed to be able to deploy the latest version, so that meant any .NET 3.5 application required installation binaries for .NET 1, 2, 2.5 and 3 ON TOP of 3.5. In this case, only the installer is bloated.

One workaround is a web installer, which downloads only those components that are actually not present on the target system - and this can be a gigantic size/bloat benefit. Of course it does limit your installations to systems that have internet connectivity.

This is especially bad on the Linux platform. Annoying on the Windows platform, but makes me tear my hair out when working on Linux based projects! — Brian Knoblauch, Dec 12 '11 at 20:04
This is especially bad on the Windows platform. Annoying on the Linux platform, but makes me tear my hair out when working on Windows based projects! — Paul, Dec 12 '11 at 21:37
at least on Linux you can just run apt-get or yum and all the deps are installed in short order. Windows... not nearly so easy. — gbjbaanb, Jul 07 '14 at 07:49

score 3 · Answer 3 · answered Dec 11 '11 at 17:27

I think a lot of it has to do with layer upon layer of library code. Obviously when you use a library you don't use everything in it, so that excess adds up as you include more and more libraries.

Combine that with the fact that the cost of an hour of work from a programmer is getting increasingly expensive while the processing power/storage of the typical computer is getting cheaper by the year, you see that it is actually more cost efficient this way.

score 2 · Accepted Answer · answered Dec 11 '11 at 15:34

My guess is that there are a lot of features that someone thought was a good idea. However, if a lot of people all have separate ideas that get put together into one application this is how it can become so complicated. I wouldn't blame the developer in the case of large corporate products where there should be product managers that have a responsibility for what is in the product and how to optimize it from various perspectives.

Another side to this would be the technical debt that likely doesn't get managed well in most cases as it isn't seen as a great investment of time. I'd suspect new features and bug fixes make more sense than refactorings or other debt tasks that may appear to have little immediate business value. How often would a team of developers get a couple of weeks to clean up legacy code if the code base is rather old? My guess would be not often.

score 2 · Answer 5 · answered Dec 12 '11 at 10:20

"We need something to do X. Let's use library $BIGFATLIBDESIGNEDFORSOMETHINGELSE, because I used it in a different project"
"I think we don't need this code part anymore, but to make sure that nothing breaks, just keep it"
No or not enough unit tests, which lead to
No refactoring
No tracking, where settings have been stored over the years, so now the settings are everywhere
...

score 1 · Answer 6 · answered Dec 12 '11 at 19:58

It is a vicious cycle where everyone in the cycles of despair can be blamed. One cycle of despair consists of the following steps:

Business people asks for bloated features.
Developers implement the bloated features even though they know that they shouldn't.
Customers pay for bloated features even though they only want the product but not the stupid feature.
Business people believe that customers want the bloated features.
Go to step one and repeat.

How do you stop it? There is no easy answer on how, but it is clear that in order to stop the cycle then one of the steps has to be broken. Thus it can only be broken either by business, developers or consumers taking a revolutionary action.

score 0 · Answer 7 · edited Jul 07 '14 at 07:36

An engineer tried to optimze a module but introduced several customer issues. Then, his manager said no. Then, the engineer decided to not "make trouble" until trouble troubles him.
For a complex system, the vendor already added many patches and fixed thousands of bugs to make it stable in the customer's environment. It does not have good quality from software's point of view but it works. No one wants to rewrite it to fix the same amount of bugs again.
for backward compatibility reasons, even if a feature is not popular in the market, we need to keep it there.

score 0 · Answer 8 · answered Jul 07 '14 at 08:09

Its invariably laziness, that's what causes the bloat. (or the mud as in the seminal article on this subject, the Big Ball of Mud)

For example, where I work we have a "legacy" C++ application that's nevertheless quite well designed, The clients talk to an API that talk to a server that does DB work. All sensibly done. Recently we needed an additional module, but rather than implement it correctly the dev decided to implement this in .NET, and worse, he decided that accessing data via the API was too difficult (its not but...) he would make DB connections directly. So you see how this kind of mess happens. (and all with the agreement of the TA who put "quick" over "good")

I've seen this kind of thing before too - at an old place, a small part of the GUI was html, as some dev thought it a good idea to write the data in html and have the GUI display that. So 1 small part does something different to the rest.

In short, laziness is bad, and consistency is good (regardless of the technology used). I'd rather have an all-MFC application than one that is part MFC and part Winforms and part WebGL with many different back-end architectures tying it all together.

What are the causes that lead to an overbloated software?

8 Answers8