Without fail, when I walk into a new company I can guarantee one thing: the technical team will have old computers. In some cases, the machines are positively archaic, which to me means more than five years old. In almost all, the computers for the developers and QA folks will be at least two years old, underpowered, not enough memory, and slow hard drives. In fact, I cannot think of one company I've been with in the last decade where one of the first things I did was start replacing hardware.
Why is this important? Developers code for a living. That means running editors, debuggers, source code control systems, compilers, and a few other things, all of which can be time-consuming. QA folks do much the same, but often have even more things going on at a time than developers. So, any delays in the hardware they are using adds up to wasted time and frustration for the employees. How big a deal is it? One company I walked into had a team of about 70 developers all using machines that were between three and five years old. Most had 2GB of RAM or less, a slow hard drive (ATA) with only a few hundred megabytes of capacity, and a CPU that went back to the Pentium Pro days. When the developers had three or four things going on at once (Outlook, TFS, VSTS, editor, etc) the amount of swapping become annoying. Try to run a compilation of their C++ .NET code and they could wait ages. I timed one of the lead developers' machine at 40 minutes for a compile, during which time he would get up, go for a walk, or generally be unproductive for that amount of time. Do two or three compiles a day (not uncommon) and you have a couple hours totally wasted. Multiply that number by 70 developers and you've got days of wasted time every week! All because the computers were slow!
As soon as I arrived and talked to the development team, this issue became an apparent frustration point for everyone, and all because management didn't see the need to upgrade the machines (in truth, I suspect the developers never made the case properly). So, I started a massive replacement program, buying and replacing fifteen machines a month (to keep IT costs under control), but making sure the new machines would last two or three years and meet the team's needs. Each machine had a quad core CPU, 16GB RAM, and a fast hard drive. Even with the new hardware, compilation time dropped but only by 60% (so it took 15 minutes instead of 40 minutes). That still added up to wasted time, so we added SSDs for the main OS drive and the compilers. That dropped the compile time to less than eight minutes! A $1,500 investment in hardware saved over one hour of developer time, per developer, per day. Do the math and it's a savings for the company after a very short time.
Replacing the hardware had some interesting side effects. The first was a general improvement in morale. Developers wouldn't be bored while their machines cranked out the latest executable (in fact it was just enough time to amble to the washroom and the soda machine then check email), and so they felt more productive. The second effect was an improvement in quality, which I attribute to the fact the developers would be able to run more compiles to test different code, more often, without feeling it was a total waste of time. The third effect was that the team put in more hours in the day, as their hardware didn't drive them crazy and actually let their brains run as fast as possible. Finally, the team started coming up with more "new" stuff for the applications, since they had the time to experiment and try "what if..." scenarios. In the end, considering the small investment in the hardware, there was a huge payback in productivity for the development group.
That doesn't mean you have to go crazy with liquid-cooled oct-core CPUs and crazy-fast RAID 10 disk arrays. All it means is obsolete hardware (meaning more than two years old, typically), should be replaced for anyone who needs the speed. Essentially, that's the technical team! Sure, the accountants and lawyers and marketers can appreciate a faster machine, but whether they can use the power is debatable and should be left to particular circumstances for upgrade decisions. Since I upgraded all the tech team machines, we trickled those upgraded machines to the rest of the company after two years, when we continued with the upgrade policy, doing a dozen machines or so a month. Costs were controlled, hardware was bought in small bulk for discounts, and no one felt as though they had obsolete equipment.
In general, technical teams should have fast equipment. You can bet their home machines are fast, so why should the machines they use at work be any slower?