Should developers have administrator permissions on their PC

Should developers have administrator permissions on their PC or is giving them power user access sufficient?

Some comments:

• If they want to try out some new application that would need installing, then they could try it on a virtual machine and later get the network administrator to install it for them. Do you think that would work?
• Is there anything that a developer needs to do on their PC that would require administrator permissions?

The answer is 'Yes'. Developers will need to frig with system configurations to test items, install software (if nothing else, to test the installation process of whatever they happen to be developing), poke about the registry and run software that will not work properly without admin privileges (just to list a few items). There are a host of other tasks integral to development work that require administration privileges to do.

Bearing in mind that development staff do not necessarily have root access to production systems, admin rights on a local PC does not significantly compromise security of production systems. There is almost no legitimate operational reason for restricting admin access to local PCs for staff that need it to do their job.

However, the most important reason to provide administrative access is that setting up a compromised or second rate development environment sends a message to your development staff:

'We value your work so little that we are prepared to significantly compromise your ability to do your job for no good reason. In fact, we are quite happy to do this to cover our own arse, pander to the whims of petty bureaucracy or because we simply can't be bothered. That's just the best case. The worst case is that we're really the type of control freaks that view it as our perogative to tell you how to do your job and what you do or don't need to do it. Make do with what you're given and be grateful that you've got a job at all.'

Generally, providing a second-rate (let alone fundamentally flawed) work environment for development staff is a recipe for the natural consequences of pissing off your staff - inability to retain competent people, high staff turnover, poor morale and poor quality delivery. Going out of your way to do so - particularly if there's an overtone of pandering to bureaucratic whim - is just irresponsible.

Bear in mind that your staff turnover doesn't just incur costs of replacing the staff. The most serious cost of staff turnover is that most of the ones that stick around will be the deadwood that can't get a better job. Over time this degrades the capabilities of the departments affected. If your industry is sufficiently close you can also find yourself getting a reputation.

One point to note is that administrative privileges are far less of an issue for development on unix-oid or mainframe systems than it is on Windows. On these platforms a user can do far more in their own domain without needing system-wide permissions. You will probably still want root or sudo access for developers, but not having this will get underfoot much less often. This flexibility is a significant but lesser known reason for the continuing popularity of unix-derived operating systems in Computer Science schools.