In many large companies security considerations mean that developers do not have the system permissions necessary to install their own software, which can lead to reduced productivity. How does a company like Google, which is known to be both innovative and developer-centric, tackle this problem?
Add a comment
|
6 Answers
Developers should always develop as regular users of the machine for two (there's probably more) reasons:
- Developers are human. They try to go to untrusted sites. They accidentally delete things. If their day to day account does not have administrative rights, then they minimize their exposure.
- If they develop using the rights their end users should have, then it is more certain that their code will work as expected.
I develop using a user account. I have an administrative account that I use for installing software or configuring the machine (Windows or Unix, it doesn't matter). The last thing I (and my employer, for that matter) need to do is spend a day or two wiping and reinstalling my computer (even if this consists of restoring backups) because something messed up because I was logged in as an administrator.
-
I should also point out that when I was a systems administrator, I also had multiple accounts for the same reasons. The last thing you want to do is be an Enterprise Administrator when you're sifting through those questionable news group sites looking for that one guy who had the same problem as you and posted the fix.– shuflerJul 29, 2009 at 23:49
-
-
My answer doesn't answer the op's question. Just some friendly advice.– shuflerJul 30, 2009 at 19:19
-
It may be an idea to use VMs; i.e. your user on your corporate computer means you're working with regular rights, but on any of your dev boxes you can create developer and test accounts as you need, can install what you want, and can backup and copy the image as needed. Having admin rights gives you more autonomy which generally improves your speed. There are always trade offs, so there's no golden rule - people should just make the best decisions they can. Feb 18, 2015 at 15:32
-
@JohnLBevan I think that's what my 6-years-ago-me was trying to say. Isolate your development and operate using accounts with least permissions. My answer was assuming development in a VM (and I know this because at the time this was how I was developing) though I realise the question may have been about the host machine. Same rules in either case. Use a user account for most things and prompt/elevate to an administrative account for administrative tasks.– shuflerFeb 18, 2015 at 17:53
I am at a large company where I do not have admin rights to my computer. Everything has to be requested and approved. At first I was a little annoyed by this, but now it is just part of the process. I got my Visual studio, notepad++, and such just fine after all the paperwork approvals were sent in. I even mentioned netbeans/java sdk in case a piece of work required it. The CIO and associates want to keep control of thier network and have strict software guidelines due to the type of work. They do understand though that I am developer and I require more access than other office staff. I came from the IT field into Software Development, so I have always been used to full machine access. The more I work with things though, it is not as big of an issue as I thought it would.
So far, I have not done any software which requires admin access to user machines, so it has not been a problem yet, but it could see it being a problem in the future.
I remember reading an old article about Google engineers years ago. They're allowed to use whatever tools they need to aid in their task which is pretty nice. I'm sure if you 'google' your query at google, they'll be a few articles describing their work environment.
Most companies (that understand software) that I've worked at as a developer do allow some flexibility in terms of software as many programmers are very particular about their own tools (vim vs. emacs; textpad vs. notepad++, etc. etc.). Most common is administrative rights over their local machine. As expected, normal security rights (passwords, groups and such) apply to machines beyond the local workstation such as staging and production environments. So having admin to local is great and having restrictive access to database, web, messaging etc. etc. servers is manageable and understandable.
Typically developers get free reign in the development environment. I compare it to playing in a sandbox. Staging should mimic production but be tightly controlled by a few lead developers. And the production environment is usually off limits. Changes are made to development -> promoted to staging -> promoted to production (pending testing of course). Now, I realize that this methodology is the ideal. That doesn't mean everyone practices it. How google does this is beyond me. But I wouldn't be surprised if it was similar to this method.
It really depends on the office and scenario.
I tend to find when at most offices that their developers and a few other roles usually have machines that are on a network/domain with limited privileges however they generally have local admin rights so they can install and do whatever they want.
Some other offices that have strict policies tend to give their staff a locked down machine for their work network related stuff such as outlook and then another machine that is on a separate network that just has internet access for messing around on.
It makes no sense to give telesales or support full admin access when they only need to use a handful of programs
answered Jul 29, 2009 at 21:48
Small companies are good for letting you do things like this. I've worked in a few small IT companies and not only do you get root to your own machine, but you get root on all the machines. :)
answered Jul 29, 2009 at 21:49
In a small company, giving developers a free reign over their choice of tools can cause a problem if the developer then leaves the company and no-one else has experience with that tool. There's a learning curve involved that, if the developer had used the same as everyone else, would not be required.
