In a corporate environment, should developers have admin rights on their computer? Why?
- Windows 7
- Visual Studio 2008 & 2010
- SQL Server
Server Fault is a question and answer site for system and network administrators. It only takes a minute to sign up.Sign up to join this community
In a corporate environment, should developers have admin rights on their computer? Why?
Should they? That's up to the corporation. Personally I think it's fine as long as there are some understood rules.
Typically I would say yes. Things like debuggers require pretty high if not admin rights to work correctly. Developers often need to install random software which can take days or weeks to get installed when going through channels. During that time the developer is usually work stopped costing the company nothing but money, especially if the developer is a consultant.
There is both science and art in development; it isn't as simple as "knowing" what we need. If we already had the answer half our job would be moot; finding the correct approach is often iterative, and may involve multiple tools in unpredictable ways. Requiring an intermediary to install each of these (often with high latency), only to find (about an hour in) that for your scenario the "super-uber tool addon" is needed is silly.
While a VM is ideal for this, there are also a lot of development tools that cannot run (properly, or even at all) in a VM, because they themselves are a VM - and I don't mean things like JVM; I mean full machine emus/vms, such as device toolkits. Compatibility there is improving.
Additionally, most development tools have a very large footprint - much larger than "regular" tools (making VM hosting a bit more painful than you might expect), and often by the nature of being a process debugger require elevated access. Not to mention the fact that they may be GUI intensive; trying to run full-time on a VM GUI is... extremely painful.
Performance is a huge are here; would you think it was OK for users to wait 3 seconds after every keypress in Word for their key to register? I am not kidding - development tools on VMs etc can be this sucky; for most development purposes you need responsiveness. Interrupting the flow of complex logic from brain to keyboard can make it pretty much impossible to get the job done. And I hate to say it, but yes: development time is expensive.
In being a developer, I rank us a level of privilege above the basic user, but below the systems administrator(s).
I may, on occasion, need an extra library installed to get the application I am developing to work in the production environment, that being said, I have a strict rule I develop by: "For any application which requires third-party libraries, the libraries should be installed in a sandbox environment prior to production deployment and, in some cases, prior to application development."
The sysadmin I work with and I agree to this, and between the two of us, we will actively enforce that rule and delay any application deployment that has not passed the "dependency checks".
To answer your question though, yes, developers should be given full access to their own machines, but those machines should be isolated from the environment the application will ultimately be deployed on. In which case, even the application deployment should be sandboxed until deemed safe to deploy in the production environment.
Disclaimer: I'm a developer.
To me, this question (and the answers) seem to be attacking the problem from the wrong approach - that is, the debate is focusing on what admins want/need vs. what developers want/need. But you specified we are in a corporate environment, so let's look at it that way.
So let's imagine we are arguing this in front of the director of IT or operations, or whomever controls our budget, and ask these questions.
With these questions answered, you can make an informed decision rather than a passionate one.
For your specific environment, there are some things that require admin rights (see User Rights and Visual Studio) - if they are not doing those things, then you can answer questions 2 - 4.
As a consultant, I have seen both extremes of this policy, and while I always want to have admin access to a machine, in some cases it didn't make sense. And I'm not sure what is cause and what is effect, but without exception, every place that I've seen doing windows development where the devs had admin access also had MUCH higher productivity from every developer than places where they were locked down.
I think you are asking the wrong question, you should be asking:
Will a good developer work for an employer that does not give him/her admin rights on their PC?
What someone “needs” and what they expect are often not the same thing, after all you don’t need to allow a developer to drink coffee in works hours, but if you don’t…
(Make sure you make your policy clear at interview stage, otherwise you may get people taking the job that then despise your company due to the lack of admin rights – don’t expect programmers to think in a logical way about this sort of thing!)
It depends actually more on who you ask then about who actually needs it. If you ask corporate IT and risk management groups they will be all over you with horror stories (and if they are to give it to you they demand a goat sacrificed in a holy bond of promise that they will not be held responsible), the developers on the other hand demands admin rights mostly because the job is stressful and demanding enough without having to seek permission from help desk to go take a leak. The sad state of affairs is that now its more about power struggle and exerting power then it is about business and productivity needs (e.g. it boils down to who will make the other jump through hoops)
IMHO, the best work environment I've seen to this day is where the two groups are being kept separated. Developers have their own domain in the forest (whereby IT controls what this domain and its users can do in the rest of the company) and they are all local admins with experienced guys with MCSE acting as local domain admins, they have their own test environment and can do pretty much what they want and need on their local LAN with a single IT policy (no pirated software). Corporate IT is not responsible and does not render support to devs and only enforces some high level corporate rules (no facebook, porn or similar through firewall, devs not allow to mess with corporate LAN) and they all have RSA based VPNs to work from home which puts them directly inside their LAN. Neat, isn't it?
Definitely! Usually a lot of the development that goes on may or may not be in a virtual environment. Admin rights help to overcome a lot of the overrides of service handling, registry entries, and IIS locally. On the other hand, it depends on how much trust you have in your developers.
As a developer, it's frustrating when something doesn't work because we don't have access.
Depends. As a developer, one should always operate on the principle of least privileges. If you are working as a government contractor, you might be contractually obligated not to have admin access, for example.
As a Java developer, I've hardly had a need to have admin rights on my machine on an ongoing basis. However, there are legitimate cases when you need on-demand admin access (.ie. you need to move your laptop across physically separate domains, and you need to change your NIC accordingly.) That was the only time were I've really needed permanent, ongoing admin access to my machine.
Sometimes you need admin access because IT is understaffed (or incompetent or mired in red tape.) But if you work with a competent IT department, they can install the stuff for you even remotely (or by providing custom installers that will "run-as" admin and install the stuff for you by just clicking in them.)
So the answer (again) is - it depends. Do you have a responsive IT staff that can install things on demand (or within a reasonable time)? Do developers actually need it for the tasks they are paid for?
If the developers truly and legitimately need it (as in "I will literally WON'T be able to do anything without it") as opposed to a convenience (as in "I want to install whatever I want"), and if IT support is not sufficiently responsive (for whatever reasons), then yeah, they should have admin access to their machines.
Otherwise, no. Remember the principle of least privilege, people.
For corporations that are worried about security, they will have security persons dictate and attempt to enforce a policy that works with their model of development and systems. In a Windows Environment most people will tell you that you must have Administrative rights on the host they are developing on in order to perform their tasks.
This is not necessarily true...
You can create a custom policy and have all programs and functions work with development users on a system. You will just have to get down and dirty and into the nitty gritty with custom permissions on program/system directories with groups or custom groups depending on the desired design.
Most corporations will say it is very dangerous for developers to have systems on open networks because hackers could gain control and start compiling their own tools so going through the task is much worth the risk in my professional opinion.
Developers should (ideally) have two domain logins.
One that has local admin rights (for development work) and one that has the same rights as everyone else in the company. Then, they can test their work on a representative set of permissions.
This should then reduce the likelihood of ItWorksOnMyMachine-itis that appears occasionally.....
I have to (apparantly) provide the dissenting voice and say not only no but "heck no". I have no problem giving devs admin rights on a sandboxed VM that has no network access. Zypher had it almost right (correction bolded):
"1.Being admin on my box is a privilege NOT a right." These systems are corporate assets that I am ultimately responsible for. When Joe Developer installs his pirated copy of Microsoft Bob ("because I needed it") it's not going to be him that has to explain how it wasn't found before the audit. Developers routinely think that somehow the corporate rules just don't apply to them. By giving them a sandboxed VM they can follow all of the rules everyone else has to follow (since now only IT can copy files to and from the system). Magically the request system gets used by developers again, the sky is no longer falling when Joe Developer mangles his development box - he just asks for a new one (or a restore if he's asked for backups)
Mr. Denny mentioned developers costing money when they have to wait for apps to be installed, A. hello ... my time is usually just as valuable as Joe Developer (usually more so since I keep the exisiting crapware running- and do I really have to mention all the time spent helping Joe developer debug his last masterpiece), and B. when dev goes overbudget because they were waiting for an application and try to blame IT for it I'd say:
Your lack of planning for what you need to write software is not my responsibility, we have a standard set of tools and if that toolbox is missing what you need you should have had your requests to get more tools expedited rather than attempt to make me jump thru hoops to get it for you because your deadline is tomorrow.
Having said all this, locking down the desktops of developers stinks, if you could weed out the crappy developers that think thye are entitled to watch their baywatch collection and are outraged to learn they can't install babewatch player to view them ("but it's open source") you might be able to loosen up. But for every great developer out their that "gets" it, there's 10 more that your company is going to hire for that 200 million dollar vertical application instead, and that's who you need to watch out for.
EDIT: It's certianly quite possible that the developers I've been exposed to are unusually dull (polling the current crop only 1 has heard of stackoverflow, to give some level of benchmark). The starting point of view that I begin with is "what do you need to do what the company is paying for you to do". If you need admin rights you get them, but you shouldn't stqart with them and if I can give you a box that frankly I don't care what you do to it and that works then we are both good to go.