You can hold on to old machines for only so long. Eventually equipment has to be replaced. Doing so requires a strategy. How do you decide who gets what machine in your organization?


In Classics Rock,  I ran a poll asking how you determine when it’s time to retire an old PC.  The most common reason TechRepublic members gave was when software or needs made it mandatory that it was time to upgrade.

What was more surprising, however, was the fact that only 14% of respondents said that they upgraded machines on a regular schedule. Replacing machines on a regular schedule makes it easier to plan who gets what and to standardize on machines for purchase; however, it can also be more expensive because you have entire classes of machines all going off cycle at the same time that need to be accounted for. Therefore, it can make sense to replace only individual units either when they can’t be fixed or when software forces you to, as two thirds of you said.

No matter how you decide when it’s time to get new equipment, you need to decide who gets it. Some organizations pass out new equipment based on needs. Others will pass out equipment to those based on who yells the loudest. Still others pass out equipment on a trickle-down approach.

The importance of proper assignments

During the discussion, I made the following comment:

Developer machines
I’ve always thought that developers should be forced to code on or at least TO machines that are 2 – 3 years old. Giving them machines that are faster and more powerful than the ones used by the average user merely encourages them to create “bloated” code. The programs work great on their whiz-bang units, but then drag on the slower production machines.Microsoft programmers should code on nothing but Pentium IIs…

The comment was made only partially in jest, but many of you agreed. The sad fact is in an effort to make programmers more efficient so they don’t have to wait so long for programs to compile, they’ll get some of the newest and fastest units in the department.  Their coding skews to the level of the equipment they’re coding on and then doesn’t always run efficiently on older machines in the organization. Even if programmers test on old equipment, the testing sometimes doesn’t always catch the problems.

However, you can’t have engineers and programmers developing on 486s while the receptionist answering the phone is running a quad-core 64-bit machine either. There needs to be some type of balance somewhere. It’s important, especially in an era of tight budgets, to make sure that you properly allocate resources to those that need the power without over-spending.

The trickle-down theory

What happened one place I worked is what happens in many organizations I think. Invariably, someone higher up in an organization, whether at C-level or just a higher engineering position, wanted a new piece of equipment. There didn’t need to be an official reason or business case — they just wanted it, and it was purchased.

Then we’d play a game of shuffling the deck chairs around. We’d determine who lower in the organization needed an upgrade, and we’d move the machines down the organizational chart until the oldest and slowest machines dropped off the bottom.

This theory works only if you have a small organization or if you can restrict the number of moves along the way. It’s also effective only when there’s a big gap between the machine that the trickled-upon user is currently using compared to what would drip down.

Naturally one of the things you have to watch for in this strategy is a Class Envy that can occur. Users farther down the chart may become resentful of the strategy. That can translate into problems working with them if they decide to attach that strategy to you personally whether or not you have anything to do with implementing it.

How do you assign machines to users?

What strategy do you use to assign new machines to users? Take the poll below and sound off in comments.