Strategy Letter IV: Bloatware and the 80/20 Myth

greenspun.com : LUSENET : Joel on Software : One Thread

Hi Joel and the readers,

I have just read the "Strategy Letter IV: Bloatware and the 80/20 Myth". I do not want to argue on whether the 146 MB of Excel 2000 means that it is a bloatware or not. I will start with the definition of bloatware that was used in the article:

"software that provides minimal functionality while requiring a disproportionate amount of diskspace and memory. Especially used for application and OS upgrades."

I do not hate Windows, and I do not love them either. I think that one can write a good application for Windows, and one can write a bad application for Unix. I agree that the OS "that I do not like" was a sufficient reason for starting religious wars in many cases.

One should not compare the things that cannot be compared. Here I meant the "80/20 myth". I think that it is a bit unfair to compare the results of free software activities and the commercial ones. While the free software activities are powered by nice visions and struggle for better solutions, the commercial application development gives programmers food. The same way it is unfair to say that the 80/20 is only a myth. The reality is not that simple.

Unfortunately, the quantity of features is used for measuring the quality of a software in the bussiness world that is based on the competition. Unfortunately, many users are measuring the software that they want to buy this way. It is difficult for them to find better criteria. So, I do not think that it is bad to "... give my software features that has also a software by other company".

What is a crucial point here (IMO) is HOW the feature is built in. Whether it is only added inside somehow or whether it fits smoothly into the internal architecture. In other words, whether the feature gives the user something that can be appreciated without removing other desired features (like ease of usage, speed, size, portability, ease of installation, etc.), and whether they can be combined with the existing features. That is the difficult part of software development.

What should be applied when discussing a quality of a software product is the Occam's razor:

"Do not multiply entities".

It is also known as "The thing is not better if you cannot add something more; the thing is better if you cannot remove anything without loosing quality." From that point of view, my personal observation is that adding 10 new features to 100 should not produce the 10 % increase in size. Well, this is simplified, but I hope that you understand what I mean. Author of books on software development explain that a complex system should add new functionality by combining the existing building blocks rather that by writing the new blocks. The summary in the form of the "5 attributes of complex systems", as stated in Booch's Object Oriented Desing (I hope I remember the source well), should be carved to stone. The stones should sometimes be thrown on heads of the people who are responsible for software development. This is my view of how bloatware term should be interpreted.

Now, the question is whether the Excel 2000 could not be written so that the word "bloatware" would not come to anyone's mind.

What came to _my_ mind when reading about the size of the Excel 2000 was another article from Joel on Software with the title "Big Macs vs. The Naked Chef". Here I can also see the explanation for the size of the Excel 2000 (or the like software). "The Naked Chef" like companies have big chances in competition with Microsoft concerning the quality (here the size). On the other hand, they will hardly get that much money. It also means that they will hardly be able to start and win anti-monopol court cases, and profit from the court result in the same time. This also gives users to press against Microsoft. I feel that it is natural reaction to Microsoft actions. I would call it a "good-mental-health consequence" than a "mental-health problem". And definitely, the reasons that lead to such situations are hidden in the software development process.

Another point of view: ---------------------- I guess that many free software applications would be more expensive than the commercial if the time and abilities of their programmers would be measured by the same salary criteria. And perhaps not -- the Naked Chefs are very often much more efficient in their job. (I am using the term "free software" rather loosely in the sense that you are not required to pay when using it -- I know that the term means something more special.)

So, my hat off for people who decided to give the result of their work available for others -- for free. In my opinion, they are moving the World towards better future. I use their products and I like them. One can hardly complain on such software -- it is for free and you are not forced to use it (moreover, the bugs there are removed very quickly).

On the other hand, the commercial software (like MS Office) is paid by users, and I feel that I can complain if I find a bug in a feature that I want to use. If the company wants money for the product, it must be ready to repair the bugs and ensure that the product have the declared behaviour. The company should also be ready to explain why the software is that big. Frankly speaking, I do not expect that Microsoft will ever explain the things like that (at least not for free or not being under preasure ;-)

With regards,

Petr

-- Petr Prikryl, prikrylp at skil dot cz

-- Anonymous, March 26, 2001

Answers

Very unfair of Joel to hint that RA Downes was crazy to spend an hour determining that RegClean was bloated. He appears to have done the detailed work in order to answer a heckler from Redmond who disputed the reason the code was bloated. Joel also fell and scraped his knees on this one. The sort of bloat Downes found in RegClean was not rarely-used features, which Joel rationally defended in his article, but NEVER-used code and data. This stuff has absolutely no function except to tell-tale of the builders ineptitude. I was told scoffingly years ago that Windows shipped with test stubs still inside it, but what Downes found is much worse. So bad it expanded a 45K app to 1M! This is completely unacceptable under any combination of deadlines and rush to market. If 45k --> 1M, whatever gains we make in cheap hard drives and cheap ram get completely swallowed up! This bloat, of the inexcusable, value-less kind, adds cumulatively, wasting billions in forced RAM upgrades, on extra CDs in the distribution package, and sluggish performance dragged down by virtual memory and swap usage.

-- Anonymous, May 27, 2001

Moderation questions? read the FAQ