Do programmers care about software bloat?

Question

I like to think about the users of my software and what is needed to satisfy their needs. I also like thinking about the best way to write code to provide the best performance while also having something reasonable to maintain later on.

My users could care less about our ideals such as Pure Object Orientedness, Paradigms, Frameworks, Encapsulation, etc. I am getting users who are asking day after day why they always need faster hardware for software which does the same things as the stuff they bought 15 years ago. To make things worse, their old "obsolete" Windows 98 program loads and runs 50x faster then any of the modern Java/.NET alternatives. It's the difference between an instant load on an older computer vs wait, do something, wait, do something else on a more modern and "faster" computer. They also could care less about modern features such as XML configuration and can live with the little drop down windows.

To make our jobs easier, are we killing our users experiences?

Answer 1

Apparently not many programmers do care about bloat. Here is an article that shows that on many common tasks (booting, opening files, etc.) a 1986 Mac with 1986 software was slightly faster than a 2007 PC running 2007 software.

Answer 2

yep, we are. However, how many of those users would be happy running Word 97? How many would be happy when they realise that feature x isn't present?

I think this is an issue that will attract more awareness as energy efficiency becomes more important, you can virtualise a lot of your old servers onto 1 new one.. but if your apps require several gigs of ram, the number of apps that will run in such a virtual environment will be much reduced - you'll have to buy more servers, and that's going to be a problem in the modern credit-crunched, costly-power age.

I don't have an answer though, often its not the bloated programming environment that's at fault, but the users who demand web-enabled and similar connectivity and interoperation features.

Answer 3

I would argure that what you refer to as our 'ideals' aren't just about making our jobs easier, but also about improving users' experiences. Generally programmers like clean, well designed projects because they can quickly and easily change things. There are I suppose, a number of quasi-autistic types that get off on complexity for complexity's sake, but I don't think that they are the reason behind software bloat. The primary cause of software bloat, in my mind, is the economics of software development. For business reasons, software often needs to be built fast to be competitive. Unless you have a bunch of crackerjack devs, AND good leadership, the fastest way to get stuff out is to integrate as much pre-existing code as you can into your project. Pre-existing code to get things done often comes with difficult to traverse boundaries that force at least some duplication of functionality, and make a lot of it just the easiest way to get something done.

Answer 4

I have seen, and probably fallen victim to, the "New and Shiny" programmer's syndrome. A new technology (LINQ, Spring.NET, generics, etc.) comes out and we all dogpile onto the cool new hammer. Now I need some nails!!

Programming for performance is not sexy. It requires a considerable degree of iteration, testing out all but the most basic ideas. Adding new features with new, unfamiliar technologies can have huge impacts. Sure, your code is ten times more elegant and you have 50% fewer lines... but oops! It's now 50% slower. Only profiling and exhaustive testing can effectively ferret out bottlenecks.

Programming for performance is a conscious decision that must be followed through. Users will thank you for it, and so will your bottom line.

PS: I'm not saying these new technologies are not a wonderful thing, but it is incumbent on the developer to test each new widget for performance to understand the implications of including it in a system.

Answer 5

The answer is, of course, it depends on the context and the importance of performance and size compared to cost, features and maintainability.

Some developers care about software bloat, and rightly so. They deliver faster, smaller applications to their user.

Some developers care about software bloat, and wrongly so. They deliver the performance at a cost that outweighs the performance benefit (whether its initial development cost, opportunity cost in missing features, and increased maintenance costs).

Some developers don't care about software bloat, and rightly so. They deliver cheaper, more feature rich applications to their user, where optimal performance and size is not a key to the software's success.

Some developers don't care about software bloat, and wrongly so. They deliver slower, larger applications that negatively impact the user's experience.

Answer 6

Part of the reason for software bloat is feature creep. And the main reason for feature creep is that marketing wants a big long list of why you need to buy this upgrade instead of just using the version you bought before. That's why Word has a bazillion features that nobody ever uses. And people are finally starting to realize this - witness the way Google Docs has both Microsoft and Apple worried (see today's announcement of iWork.com for an example of how Apple is worried), even though it doesn't do 1/10th of the things that Word does. It does enough, and it does it well.

War story time: I used to work for a GIS company. We often came second in competitive bidding processes because our main competitor, ESRI, had a PC product as well as an "enterprise level" that ran on big VAX and Sun workstations. They would give the customer a copy of the PC version for free, and the custom would use ESRI's feature list when they wrote the RFP. One time I asked a customer what a couple of features that they'd listed as requirements actually were, and they had no idea - they'd just copied it off the back of the shrink-wrap box that ESRI's PC product came in.

Answer 7

As hardware gets faster, people stop focusing on performance and start focusing on other stuff. This is good up to a point, but the pendulum has probably swung too far, now that the phrase "premature optimization is the root of all evil" is taken to mean "performance doesn't matter at all." It just seems like programmers in most fields are actively discouraged from caring about performance nowadays, whereas in 1986, the problem was that they were too obsessed with it at the expense of just about everything else.

Answer 8

I suppose it's possible that some software devs are killing user experiences to make their jobs easier, but my own professional experience is that we're killing user experiences to make our jobs harder.

Every time I've encountered software bloat in my professional career, it's been the result of massive over-generalization and over-engineering solutions. I can count, off the top of my head, at least 5 "It does everything!" products that I work with or interface with, each with their own particular technique for modelling the entire universe. Unsurprisingly, such generalized products are amazingly slow (especially the one written in VB6) and effectively useless because, when something does anything, it really does nothing. Customers spend hundreds of thousands of dollars to buy the software, then hundreds of thousands of dollars more to pay us to configure it for them because there's no way they can figure these arcane models out for themselves.

Needless to say, transforming one of these models of everything into another model of everything, something that I spend a great deal of my time doing, is ridiculous.

I suppose 2 of the 5 are actually useful, in some level, in the field (One of them is ours, and we have some customers that aren't stuck with us purely through vendor lockin). I can't think of any reason for the others to exist, except as some architecture astronaut's *** dream.

Full Disclosure: I work in a single sector within the software industry, so I can't say that my generalizations I make spread beyond my own sector. I absolutely claim that these problems are endemic to my sector, though.

Answer 9

It depends on your platform. For PC's I would generally say no. Each year hardware gets faster, we get more memory, and hard drives get larger. Yesterdays super computer is today standard desktop, or near enough. The user interface is what matters and they want colorful graphics and lots of eye candy (that said it still has to work). Still sparse can be beautiful. I give Google as an example.

It is different for embedded systems. Here hardware changes slowly and at time memory and drive space get tight. Function is more important then looks. Indeed many times their is not a user interface or a very minimalist one.

Answer 10

If your users are so concerned about performance, why don't they run the old OS and software on modern hardware. That should be really fast.

But I suspect that if you ask them to do this, they won't be so keen on the idea. Although everybody claims that they only use 20% of the functionality of modern software, it's always a different 20%. So if you survey a large group of users, I suspect that between them they'll use 80% of the modern "bloatware" functionality.

Answer 11

Just another point of view: Java/.Net allow for much faster and easier application development.
The same application developed 10 years ago and that now loads in a nanosecond required much higher skills, and longer time, for being developed.

Is this bloat? Yes, of course. Is this value? Yes, definitely.

Answer 12

Well I guess for me it really depends on what you are considering bloat? I work on a team developing a website and I care very much about the over all bloat of our product, and try and keep the feature list in check. I am very active in constricting our codebase and streamlining our processes. This is a focused process with the end goal on becoming more efficient.

Though while doing this we have started to converge some parts of our code to include features that are rarely used. This could be considered bloat, as some parts of the toolbox are getting unwieldy. but it's a process.

So is there bloat, sure, it's always going to happen. Though for me it's a balancing act of what features do we really need down the line. If we think that there needed add them in, but when something dies it needs to die.

Answer 13

Lots of answers here but no one seems to have defined what exactly bloat is. Someone has mentioned 'features no one uses'. That's a bit tricky. Our secretary uses word and has never ever used the equation editor. A friend who is a university lecturer uses it almost exclusively.

Someone else has referred to size on disk. In the larger scheme of things, with 250GB hard disks becoming the norm is it really a big deal if an executable is 5 MB?

Someone else has mentioned performance. Is high performance analogous to less bloat? If my v1 exe that is 5MB loads in 4 seconds and my v2 that is 10B loads in 2 seconds is v2 bloated?

How would you define bloat to a new developer or better yet your non technical grandmother?

Answer 14

A funny thing about programmers/engineers: other people's code is always bloated (e.g. "Windows [Insert Version Here] is such sooooo slow because its soooo bloated," "FireFox [Current Version - 1] was sooooo much faster... its getting bloated," etc.

And yet, when its our code, we're the fist in line to try to add new features! "Hey check out my web app with the super cool grid that has frozen columns, headers, sorts 12 different ways, changes colors, etc."

Thank goodness for that spirit too... we'd still be running DOS apps on monochrome screens if no new features were ever added.

Now don't get me wrong, if no one is actually using those new features, then you know what? It is bloat... but if people are using those features (even if its not you), then its progress. If your app loads 2 seconds slower than it used to, but it saves 5 minutes a day in productivity, isn't that progress? Or lets forget productivity... say your new features make the app easier to use, so you attract a bigger audience than before. Isn't that also progress? Isn't one of our goals to get more people to use our apps?

Answer 15

There's only one mainstream PC operating system. And it's not offered in a "Lite" model. Coincidentally, the company that sells the one mainstream operating system also defines the "best practices" tools and frameworks for writing software for their operating system.

They also provide the only available mainstream office products; whose features haven't improved perceptibly in a decade. But you can only buy the latest Version, which requires the latest Version of the OS.

And if they stopped the merry-go-round, we'd all be in big(ger) financial trouble right now. Remember the other thread about the estimated 3-year life span for the average enterprise app?

If you have an engineering background, you may remember the concept of Stable Equilibrium - there's a point on the curve where moving off-center induces forces back to the center. In our industry, there's no such point.

It's cluster-bloat.

Answer 16

Of course we care, but can you make some real suggestions about how to actually change things? We are also pragmatic, and accept reality. We know what our customers are willing to actually pay us for, and we do what they want.

Are you willing to pay for 40 hours of work to write a heavily optimized program in assembly when I could hack the same program in python in 2-3 hours?

Are you willing to start paying for new versions of software when no new functionality has been added, and only change is better performance? Software developers want to eat, we can't just make things better without getting paid, and almost nobody seems to want to pay for making software faster.

Aside from some minor complaining, users with money are not demanding un-bloated software, the are demanding whiz-bang features.

Answer 17

Yes I'm semi-obsessed with it

I can't speak for other programmers, but I'm always trying to make sure the code runs as efficiently as possible.

Sometimes its the small things in everyday code such as:

• explicitly declaring a list type -> avoiding boxing and un-boxing
• defining constants, when you know that 'variable' is not going to change
• using data-reader instead of a dataset.
• Optimize, or more importantly optimize the right thing!
• Pre-compute where possible.

The list could go on. Most importantly keep reading, if you learn something new, re-factor your all code with that knowledge.