Software Bloat and Moore's Law
Regarding a line in the recent interview of Joel - How can Moore's Law justify software bloat? Software can grow *at least* as fast as hardware can. So no matter how much better your next computer is, bloated software will *still* run slowly. And what's worse, you'll have to upgrade *everyone's* workstation to the new model, in order to keep compatible with the new bloated office suite.
I definitely respect this point of view, that we're going nuts with new features. However, the consumers have spoken, and while they say they want speed, they pay for bloat.
Software bloats faster than hardware capacity expands. Why ? We have all experienced situations where the user demands interconnection between functions which mess up our nice logical deconstruction of the system. If you think of a system as a circle with functions at the edge, the interconnectedness of the system is related to the area. Adding a little extra to the circumference (user functions) inflates the area (interconnectedness) to a much greater degree. Increasing the power of a computer simply allows your computer to run bigger circles of functionality with an exponential increase in complexity.
On the topic of software bloat, it would help to distinguish between size bloat and processor cycle bloat. With regards to size, the more features you pile on, the bigger your code footprint will become. Just as mentioned by Joel, the cheaper disk space becomes, size bloat becomes more and more negligible. Processor cycle bloat is typically brought about by software layering. To get something done, you end up calling layers and layers of software.... most of which add little to what you need to do. I come from a c/c++ background so yes, I did knock VB, Perl, and other scripting languages around for a while with regards to their performance aspect. However, I am finally recognizing that all the above languages have become so pervasive in the programming world.
On Size vs Speed, remember that it's not just disk space that is affected by size bloat. The more code and data your application has to use, the more RAM your application uses up, the more swapping the user has to endure, and the slower the entire system runs as a result.
Yes, but RAM is cheap, too. And so are CPU cycles.
RAM/HD not withstanding, it's worth noting that bandwidth for ESD (electronic software distribution) is expensive. And in large enterprises, the ability to have a clean installation process (e.g., not ripping up registry settings or installing system DLLs - a common trait of bloatware) is also key.
What about all the junk in the background... In the Operating Systems course I am doing they teach you that the more programs that run at once the more CPU cycles have to be split in between programs. This causes overhead of which older operating systems had trouble with. The new operating systems like windows 2000 and XP don’t have such a problem but in saying that they have a higher overhead regardless.
Fog Creek Home