Perhaps the trend you point to reflects the downward cost of memory, both in semiconductor and magnetic form: In the days of the IBM PC-AT (IBM's '286 machine) a 40 MB drive cost $1000. (I know because I spent that much of my employer's money to buy one for our design-engineering lab). Today a 1 TB drive costs $130... no, $125... no, $120... you get the point.

Similarly semiconductor memory costs have fallen to levels that are simply hard to believe. For example, one of my mobile digital audio recorders packs an 8 GB flash card. I think I paid something like $65 for it. I don't even know how much DRAM goes for these days because the machine I bought two years ago still has as much of the stuff as I need.

Given the low cost and ready availability of memory (just hop down to your neighborhood Staples), code writers have little inspiration to write small. They are inspired to write fast and, evidently, sloppy. The result is software that is bloated, wasteful of energy (yes!), and, in all too many cases, of questionable stability and reliability.

All good points. I guess that my bias comes from being involved with so many embedded products that went to very large volumes. A dime's difference in memory doesn't seem like much, but when the device is being built 10-100 million units per year it becomes serious money. There's very few operastions managers who would turn down an additional million dollars of profit.

But a lot of my concern comes from your last points. More code=more bugs=more instability=more cusotmer complaints=more cost=job cuts=more problems. Lest anyone think that this is a fanciful scenario, just loko around.