Rethinking software bloat.

Information week.com ^ | 12/17/01 | Fred Langa

[ez2muz]

"...wheres that take it back button when you need it?"

LOL.
It'll be included in the next release but you'll need an extra gig of memory.

[dennisw]

thanks for the tiny apps link

[dennisw]

Do you really think that w/ XP Microsoft will spy on your computer for *stuff* that is not 100% kosher?

[bvw]

• People are intelligent and act intelligently.
• Software business practises are generally lawful, non-monopolistic and good.
• The people who write bloatware are the same as can and sometimes the same as do write non-bloatware.
• Bloatware is not inherently superior to non-bloatware. Either can do the job.

There are other reasons why Bloatware nearly always beats non-bloatware.

[damnlimey]

Welcome,there's some interesting and useful stuff there.

[r9etb]

What do you think are the real reasons for "Bloatware"

Process, schedule, and cost.

Once you get something running, and an OS built around it, the financial and time arguments against brand-new development, and in favor of "adding on and working around," is well-nigh insurmountable.

[ArGee]

People are intelligent and act intelligently.

Well, that's the answer I would have chosen. I haven't seen much in the way of evidence to back up your claim. Remember the NASDAQ bubble?

Feel free to post your own list of possible answers.

Shalom.

[bvw]

If one builds a a grand building that way, the whole cobbled-together thing falls down.

Bloatware doesn't. Sometimes, but not often.

In practise -- Bloatware grows better than non-bloatware. Why?

Something different is going on.

[bvw]

The NASDAQ is still around.

[JoeSchem]

They're not selling new machines at 1/10th the price because people don't want them.

Maybe so, but the other day I was in a branch of the Bank of America, formerly SeaFirst, and saw a ghost on every desktop -- the old black-and-white, postcard-sized screened Macintosh. And I thought, "Why not?" It's probably all they need . . . .

[usconservative]

Unfortunately, too often today programs seem to be bigger *and* buggier, so linking libraries may not be the culprit there.

Your very well made points aside, I was only addressing the bloatware issue. If you want to discuss the bugginess of bloatware, that's another matter entirely. :) Regards,

[bvw]

The bugginess of bloatware is absolutely a necessary part of its success. A very significant and necessary part.

[Bitwhacker]

Don't you dare take me off the bump list!! Thanks for putting me on the list, btw...

[2 Kool 2 Be 4-Gotten]

Two observations

1. There is a real apples and oranges comparison in the original article when the Linux distribution is compared with the Windows operating system . Sounds good at first read, but it really is a specious line of reasoning. The linux kernel, the shell, a GUI and the basic Unix tools should take up very little space indeed. All the other stuff in a linux distribution are truly applications. This may seem like a minor difference but it is not, as Windows has massively blurred the line between application and OS. The result is a bloated OS that is not well enough insulated either from misbehaved applications (IE being the best example that I know of) or for that matter from code in the OS that more properly belongs in an application. The model of a small OS kernel, and layers of functionality on top of that culminating with the application is a good one, and one that Microsoft has always ignored. This is a real issue.
2. Secondly there are other very legitimate reasons for code size increasing. There are dozens of people on this forum who choose to cast the issue in a moral light. Laziness, incompetence, poor management, time to market issues, etc. etc. There may be some of that but that is not the driving factor. I would submit that one reason for code bloat is the simple idea that working code is no small matter. If you have been working on a project for 10 years and it has been field tested and battle hardened, and thousands of bugs have been filed against it, are you going to rip the damn thing and start over to satisfy someone's aesthetic sense? I don't think so. You keep going in an incremental fashion because it works and it is just too damn expensive to take a chance with starting over. Do you want your bank, or your hospital or your airliner to pull out their working code in favor of some genius's slimmed down, svelte code? I don't and I don't think you do either, because the old, working (bloated code) has already been through that weird corner case that will "never happen" (but somehow did) and some engineer found a fix for it, and that's one more bug that's not going to bite you in the a** when you can least afford it. It ain't a moral issue, it's just a practical one, it's hard to come by good, working, robust code and when you get it you stick with it and just tinker or add on. That's the nature of the beast.

[fnord]

cool site; I have and use a couple of those progs. maybe when I retire I can get back into the programming habit :-)

[damnlimey]

Yep,did you check out "menuet OS"an OS that fits on 1 floppy.
I believe it can be run from the floppy as well.

[Bush2000]

IIS should not be installed by default on Windows Server installations. It is sufficiently complex that it needs a lot of configuration. Either that, or it should be completely locked down with absolutely no permissions at all.

[supercat]

My preferred text editor is PC-Write version 3, circa 1988. I still use it, and it runs nicely on modern machines. 'Course it ran pretty well on my 4.77Mhz 8088 also.

What is the difference between hardware and software?

As time goes by, hardware gets smaller, faster, and cheaper; software gets bigger, slower, and more expensive.

[supercat]

I actually have one more thing to add to this discussion -- OO programming also can increase code size tremendously, in return for adding flexibility, stability and code reusability.

Unfortunately, for some reason, development systems today have gotten terrible at controlling 'dead code' bloat. It used to be normal for development systems to only include code which could actually be called; now it seems they throw in everything.

Part of this I think can be blamed on the design of C++, which does not allow the necessary interactions between the compiler and linker to determine what code is actually needed. As a simple example, many virtual methods are in practice never overridden; a static analysis of the software would be able to detect this and replace all of the virtual-method calls with "simple" CALL's. Unfortunately, this condition can't be detected until link time, after all of the code has already been generated.

It would be interesting to do a static analysis of some modern software and determine what portion of the code can in fact ever be executed. I would not be surprised if almost half the code in today's bloatware is 100% completely useless.

Another thing which should be noted: many of the applications which 'should' require fact CPU's seem to benefit from them. Quake, for example, runs much more nicely on a faster machine than a slow one. Many other applications, however, seem to have random 'snooze times' [where the application stops responding for a few seconds]; these seem independent of CPU speed. It would be interesting to know, during the times that someone is actually waiting for the CPU to do something, at what efficiency the CPU itself is running [as opposed to waiting on cache misses, etc.]

[supercat]

One of the things I like about my job is that there's value in getting a piece of PICmicro or 8x51 code into a small code space. My greatest accomplishment in that regard was squeezing a brush pressure control module, including a terminal-based setup function, into a 1Kword part [that was a tight fit, but the 16F84 was at the time the only in-circuit reprogrammable PIC available]. Too bad there's not much need for such skills in the PC world...