Bloatware

Wikipedia has "Software bloat is a process whereby successive versions of a computer program become perceptibly slower, use more memory or processing power, or have higher hardware requirements than the previous version whilst making only dubious user-perceptible improvements." My definition is broader in that it includes unnecessary complexity in the user interface.

We have a new microwave. A domestic microwave is essentially either 'off' or 'on' for a period of time. Granted there is also the sometimes used complexity of pulsing on and off for defrosting.  So why the bloated user interface with its need to press multiple buttons to do the most common function when one would do?

Lewis acknowledges the malady with " 'If that's all they mean, why do they wrap it up in so strange a fashion?'. 'Doubtless,' said Arnom (and I could tell that he was yawning inside the mask, being worn out with his vigil), 'doubtless to hide it from the vulgar.' "

Way longer ago Occam acknowledged it with his famous "lex parsimoniae" principle of parsimony, economy, and succinctness.

Conversely I belong to a church where a sermon is not worth much unless it is at least an hour long, never mind the content. I was asked to comment on one recently - the man had a good point, I noted, but he could just as well have said it in a sentence and then sat down.

The most common negative criticism I have heard concerning Peter Jackson's The Desolation of Smaug is that there is too much padding, too little plot - it is bloated.

Whilst the principle applies across the board it is perhaps most noticeable in software. I was watching a 4-year old playing a educational "game" - the user interface was so ridiculously convoluted doubtless intentional to prepare for later life.

The programming language 'C' claims to be as efficient, as close to the computer's native assembler language, as they come. And yet it is bristling with unnecessary paraphernalia.  And how about the 'C18' construct:

unsigned char n = 7;       //8-bit
unsigned short integer r;  //16-bit
r += n * 200;

The compiler has to translate this to assembler. In assembler the basic multiply instruction takes two 8-bit values and generates a 16-bit value, as one would expect. The 'C' statement starts with a 16-bit variable 'r' so one would expect the arithmetic to be carried out to at least 16-bit precision but, no, although the compiler has to use the 16-bit result assembler multiply instruction, because 'n' is 8-bit the compiler chooses to trash the upper 8-bits and gives the answer r = 120.  Without so much as a warning message.

'C' also promises tight code, but fails to deliver. True, it does make programming easier, faster and less prone to error - that is an essential quality of any higher level language, but it is not true that it avoids bloat. I have written similar code for embedded systems in both assembler and 'C' and the latter is far less efficient in terms of amount of code memory used.  But at least with 'C' it is easy enough to include sections of assembler for critical functions if one is fussed about speed or code efficiency.

The modern GUI (graphical user interface) lends itself to bloat with its keyboard / mouse duality. Programmers seem to think that both have to be used whatever the function. The mouse is good for graphical operations but a keyboard wins for text, so why mix the usage?  Having to use both is wasting my time.

My opening quote Wikipedia compares the amount of memory and processor speed required by successive generations of MS-Windows - OK I know that good features have been added during that time but no-one can convince me that I really need at least 2Gbyte of RAM, a 1GHz processor and untold amounts of hard disk space just to do word processing an social networking (let's face it - that's what most people use their computers for).

I use (2D PCB) CAD software 'BoardMaker' that runs under MSDOS on a 486-DX2-66MHz computer with just 640Kbyte of RAM. It is lightening fast, the user-interface is ultra-slick, and it just WORKS.  OK the memory limitation does set a maximum complexity to my designs but I haven't reached the limit yet. Don't tell me I need a bloated CAD package that only runs on a super-work-station - although doubtless one day I shall be forced to buy one.

Apple preen themselves on minimalistic design, but minimalistic is not necessarily the opposite of bloat. To get one button to do everything may not be that efficient even if it looks nice.

No, the criterion is not whether it looks nice, whether it has more flashy gimmicks that the competition, whether it boasts a 64-bit processor - the criterion is: does it do the job I want done efficiency and without falling over.  What are your expectations when you buy a car - that it is easy to control, economic and reliable, and above all safe are expectations so paramount as to be hardly questioned - and yet those are the very features that get missed with bloatware.