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?
We are team of 5 developers and build web applications
Solution 1:
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.
Solution 2:
Developers should have full and total control of the machine they are using. Most debugging tools require admin permissions in order to hook into the runtime of the application they are building.
Further, devs frequently download and try new things. Adding additional steps such as needing a network admin to come by and install something for them simply frustrates the dev and will quickly make life hell for the network ops person.
That said, they should be an admin on THEIR box, not the network.
Solution 3:
Yes and no.
Yes, it saves lots of time bothering system support.
No, your users don't have it so don't count on it.
We develop with admin permissions and test without. Which works out right.
Solution 4:
Local admin yes, for all of the reasons stated above. Network admin no, because they will inevitably be drawn into network administration tasks because "they can". Devs should be developing. Network administration is an entirely different job.
Solution 5:
Developers normally need to do things that the average person wouldn't, and so should normally have administrator accounts. Making them hop through awkward hoops wastes their time and demoralizes them. There may be exceptions in high-security situations, but if you can't trust somebody with an admin account you sure can't trust their code.
They should also have an available account of the same permission as their users (more than one account if the pool of users has different permission statuses). Otherwise, they may just develop something cool, deploy it, and then find it won't work for the users.
There are also too many ways to screw up computers with admin accounts (yes, I've done it). The IT department needs a policy that they will re-image a developer's computer if they can't fix it quickly. At one place I contracted at, I had to sign a copy of that policy to get my admin account.
This is a pretty Windows-specific answer. In Linux and other Unix-y systems, developers can more often get by with user accounts only, often don't need another account for test (if they've got an account they can sudo with, they do know when they're using the sudo, but they may need one with the same group permissions), and can do incredible amounts of damage to the OS very easily, so the same IT policy is necessary.