One of my first lessons about IT economics came 16 years ago courtesy of Usenet. Back then, Apple had just released the Mac IIci, a slightly faster version of the Mac II cx (which itself was a Mac IIx that was half as wide, and half as many slots).
Back then, there were two Mac product lines for Apple. The cheap stuff (i.e. a couple of versions of the Mac SE, which used a 8MHz 68000), and the real stuff (the Mac II series, which ran at 16MHz, and used 68020s, 68030s, and at one point a 68040). The one differentiating factor between the IIcx and the IIci was that the IIci was 56% faster -- it was the first Mac use a 25MHz 68030, instead of the "standard high speed CPU," a 16MHz 68030.
This was back in the day when computers were expensive, when the rule of thumb was "the computer you want costs $5,000, but the computer you can afford costs $3,000." (Back when $3K was real money...) Generally, if you were doing real work (like writing software, for example), and working for a real company (not just in your basement), then you probably had some variant of a Mac II, which was a rather expensive proposition. (Mac SEs were good for putting a computer on every desk, or as something "affordable" to get you through college.)
According to this usenet post, if you follow the logic, you're buying your most expensive hardware for your most expensive employees. For software developers, this means that you want them spending as much time as possible during their 8 hour day (bear with me here) working on code, instead of waiting for the compiler. If it takes 20-30 minutes to rebuild a piece of software, then (a) you want the fastest compiler available (including features like pre-compiled headers), and (b) you want the fastest computer you can get.
Assuming that a rebuild takes 20-30 minutes, and that a developer will need to rebuild maybe 2-4x a day, that's almost two hours lost out of each day's work. What's you're developer doing? Probably reading MacWeek, InfoWorld, checking usenet or going down the hall to grab a cup of coffee. Chances are that even if the compile is done in 30 minutes, he's not going to be back as soon as it's ready. So that enforced 20-30 minute break can easily expand into 30-45 minutes, 2-4x a day.
The argument continues that even if you bought a brand new top-of-the-line Mac IIcx in January, it's still a bargain to throw it out the window and replace it with a Mac IIci. If nothing else, the compile times are reduced by a third. This means that your developer might be able to get 3-6 rebuilds done per day, which has a direct impact on your delivery schedule. It also means that each compile will take 15-20 minutes, making it less likely to wander aimlessly through the halls "waiting for the compile to finish", and thus spending more of his time doing the job you're paying him to do. Add all that up, and the thousands of dollars spent on a new IIci mid-year are easily recoverable just through increased productivity alone. (Remember, these are going to be among your most highly paid employees...)
Read between the lines, and you can see the same old hardware envy hackers have had for decades. Last month's top of the line machine always loses its luster as soon as the next machine comes out.
Nevertheless, that doesn't invalidate the economics of the situation. Throw a sufficient amount of money at a computing problem, and productivity increases. Overwork your machines (or underconfigure them), and productivity decreases.
Which makes it all the more infuriating when a server used by a team of developers is swapping like mad because it only has 4GB of RAM, and is fluttering with a 5GB swap file. Or when developers are processing (and re-processing) gigabytes of data that can't be kept online, but must be squirreled away on CD, on other servers, and periodically deleted and restored. Or when the machine is slower than a frozen sloth travelling backwards in time, and compares unfavorably to any machine built this year.
These lessons aren't new. They've been learned and relearned for at least 30 years. What's different now is that the kind of resources needed to solve CPU, Memory and Disk problems are cheap enough that you're probably carrying enough capacity to fix the situation on your hip or in your backpack.
</vent>
