This is the correct answer. Developers should/must have admin access to their development workstations but should NOT have access to production systems, dbs with sensitive data etc from those workstations.
Programmers need admin rights because these allow them to work efficiently without constantly needing to bother IT for access. However, it depends on the organization. Allowing programmers to have admin rights also brings with it cybersecurity and malware risks.
UAC notifies you when changes are going to be made to your computer that require administrator-level permission. These types of changes can affect the security of your computer or can affect settings for other people that use the computer. Although you shouldn't see this message when you open your own files.
Local accounts with administrator privileges are considered necessary to be able to run system updates, software upgrades, and hardware usage. They are also helpful to gain local access to machines when the network goes down and when your organization faces some technical glitches.
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.
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.
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.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With