Do Your Developers Have Local Admin Rights?

plover writes "I work as a developer for a Very Large American Corporation. We are not an IT company, but have a large IT organization that does a lot of internal development. In my area, we do Windows development, which includes writing and maintaining code for various services and executables. A few years ago the Info Security group removed local administrator rights from most accounts and machines, but our area was granted exceptions for developers. My question is: do other developers in other large companies have local admin rights to their development environment? If not, how do you handle tasks like debugging, testing installations, or installing updated development tools that aren't a part of the standard corporate workstation?"

Comments

Yes

[MyLongNickName]

Yes. Both at the company I work for and the regional bank I developed for a couple years ago. It is impossible, IMO, to do many functions without these privileges.

Re:Yes

[peragrin]

isn't that the point? if the developers have to develop for a multi user and limited rights user OS they will actually build software that obeys those constraints.

I hold that windows isn't a true multi user OS until 90% of the software that runs on it can be used by a limited account. Look at any *nix. not only can you run one app under multiple users at the same time(something most windows app fail at) but all those apps are limited the privilieges of the user in question.

Yes there are apps that require different rights. but windows developers for the most part don't understand the difference between admin and limited accounts.

Maybe if they were forced to develop in such enviroments they would under the limits.

Re:Yes

[Bert64]

RH9 may be old, but not having root on it won't really be a significant detriment to a developer, unlike most windows setups...

Also, having old hardware encourages developers to write more efficient code... If you give developers the latest and greatest they will write code which is fast enough on their highend dev boxes, but uselessly slow when deployed on older hardware.

Re:Yes

[mikael_j]

Having old hardware does not encourage developers to write more efficient code, it angers them and makes them disgruntled.

I'm all for test environments being constrained in terms of hardware if that's what a real-world production environment would look like, but to tell devs they need to use 17" CRT monitors running at 1024x768@72Hz attached to 1 GHz PIII systems with 512 MiB of RAM will not make them more productive (I've had worse systems thrown at me as "developer workstations" in the last two years, good luck running your IDE + debugger + test environment on that).

/Mikael

Yeah.

[qoncept]

At my last 2 jobs developers have had security exceptions for local admin rights. The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.

Re:Yeah.

[Aeros]

In my current position and also the last company I worked with we had this policy in place. What they ended up doing is giving us two user accounts, one was low-level which was our regular account then a high-level that we switch to when we needed local admin rights for doing installs. Seems to work out fine and I hear alot of companies operate this way. It is a pain to switch back and forth but it satisfies all parties and I am able to get my work done.

Re:Yeah.

[Z34107]

What they ended up doing is giving us two user accounts, one was low-level which was our regular account then a high-level that we switch to when we needed local admin rights for doing installs.

This seems to be what Vista's UAC is perfect for! Just type in your password when you want to install something on your limited account...

</troll>

Re:Yeah.

[galego]

At my last 2 jobs developers have had security exceptions for local admin rights. The combination of money lost due to wasted time otherwise plus the fact that developers are going to cause less harm than average users is apparently enough to persuade even management.

I think there's validity to that ... for most semi-responsible developers.

However, if you are programming with security exceptions, you are likely to develop things that have/require more security exceptions (e.g. you must be admin/dbo/superuser/root to run it). It's not going to happen just because you're running as admin ... but it becomes much easier to do so ... unless you have pretty rigorous testing specifically targeting other user types. My team all has regular user accounts on their desktops and we do just fine. A couple of us (me as lead) have admin rights to maintain the system (we have a duplicated network/environment to do our work), install stuff etc.

Why propagate the Microsoft development model of must-be-admin-to-run-the-software?>

You damn well should

[QuoteMstr]

Any developer who can't competently administer his own machine is incompetent. The kind of rigorous thinking required is identical. I'd be highly reluctant to work at a place that didn't let me install and manage the software packages I needed to do my job. I've used hundreds of small programs to help me in my work, along with kernel debuggers and other tools that require administrative privileges. Having to ask for approval and installation assistance for each of them would have been impractical.

If you're worried about developers screwing up their boxes, why aren't you more worried about these developers screwing up the their code?!

Re:You damn well should

[TheRealFixer]

Any developer who can't competently administer his own machine is incompetent.

You'd think that would be the case but, in my experience, I've known a lot of extremely talented developers who had absolutely no clue about how to manage their own desktops. Didn't understand basic networking principles or basic OS functions and dos and don'ts. That being said, I still would give them admin rights to their own workstations. Otherwise I'd be spending my whole day installing a billion apps for them that they need to test or develop with, and that also ends up being a waste of their time having to wait for me. But I also have the expectation that they're probably going to need some additional care when they mess something up.

But admin access to production servers, absolutely not. I've seen way too many scary, scary things happen when developers are given unrestricted access to production systems.

Re:You damn well should

[ckaminski]

Because it's not a developers job to worry about day-to-day administration of their systems, and any one of those 100's of tools you download and install could be a trojan in disguise. If your software runs in an unprivileged fashion, it's less likely to cause rampant widespread damage.

And unfortunately, most developers have little regard for the difference between USER and ROOT (or equivalent). Until we bash them over the heads about it.

Concern for code is appropriate, but irrelevant. Too much requires root or equivalent access in todays day and age.

Give me a shell on a unix machine somewhere with a compiler, and I can guarantee almost nothing I do will compromise the integrity of said machine... up until I run sudo somethingorother

Re:You damn well should

[Deorus]

How can a competent developer not understand operating system concepts?

Re:You damn well should

[mcfedr]

but if a plumber cant maintain his toilet, thats when he's incompetent as a developer there are many testing scenarios when its easier/quicker/only possible by being root, and the need to install and use lots of software means needing someone else to do that gets annoying, and if a developer can't spot virus ridden software who can...

Re:You damn well should

[gemada]

because IT does not equal programming or vice-versa

Re:You damn well should

[TheRealFixer]

Because it's not their job, or their area of expertise.

As a case in point, here's an example I dealt with a while back. One of the best developers in the company was having issues with Remote Desktop on his XP machine. He got tired of it, so he installed VNC server instead, so he could remote into it from his other workstation. And he set it up without a password, because he didn't want to be bothered to enter it every time he connected. And in order to get it to work, he disabled Windows Firewall. Oh, and this was a laptop, that he occasionally took on the road and connected to public WiFi, like in hotels, airports, and such.

Now, on the one hand, you can say he was very competent in operating his workstation. He knew how to install software. He knew how to configure said software the way he wanted. He knew how to change OS settings to make sure his software worked the way he wanted. He did all this without having to contact anyone else for support. On the other hand, he completely opened up his laptop to attack because he didn't understand security concepts and didn't see the bigger picture beyond his own needs. But he was a fantastic developer, and one of the top performers in the company.

Re:You damn well should

[r7]

How can a competent developer not understand operating system concepts?

Operating system concepts are one thing, systems administration is quite another. Most competent engineers can install and configure software given a package management interface but few can manage a system, including their own desktop. Every instance I've known where developers had root/administrator access they regularly screwed it up.

SA and ENG are both full time disciplines and nobody can do both well. Sure they think they can, but auditing their systems/code tells a different story.

And therein lies the problem with being an SA. Everyone thinks they can do it regardless of training or experience. It's like engineers programming themselves and their companies into dead end, high maintenance, dependency handicapped, unreadable code hell. Cleaning up takes lots of time and money whether the mess was created by an SA or an engineer. Badly designed systems, like badly designed code, has derailed many an otherwise promising application and business and will continue to do so wherever developers act as administrators and visa-versa.

Re:You damn well should

[Darkness404]

Thats why you do the sane thing and you know, isolate those systems. Guess what? Development boxes aren't mission critical, if 5 of them go down you just shrug and run to the local computer store and buy the components or a new system for them. Usually development systems are a bit faster than the typical workstation (you don't want http://imgs.xkcd.com/comics/compiling.png to happen do you?), but can usually be hacked together from spare parts and not maintain uniformity that is critical for the rest of them. In general, other than software development stuff, not much else should be saved on a development machine. Same with testing. The way its set up for me (and I helped design some of it) is there are three classes of machines: Development, Testing, and Typical. On development machines they usually have generic, cheap and fast hardware, nothing saved onto the computer thats important, and developers have total admin rights over it, but they are isolated on a different network. Testing machines have the same hardware as the typical machines, the typical developer does not have admin rights except to install pre-approved things, and its hooked up to a network very similar to the one the typical machines are on. This lets us test patches, new software and other things before doing a company-wide rollout. And typical machines all have identical hardware, no admin rights for the users, and are hooked up to our main network.

Re:You damn well should

[StripedCow]

For example, I can imagine that a 3d graphics guru is just not that interested in basic legacy networking stuff (most of the networking abstractions are ill-designed anyway, from a modern perspective)

Re:You damn well should

[Anonymous Coward]

Easy - not all operating system concepts are applicable to all kinds of development. You don't necessarily need to know the stuff that doesn't overlap with your own responsibilities.

Re:You damn well should

[kbielefe]

How can a competent developer not understand operating system concepts?

There's a difference between aptitude and practical skills. I know more about the software for helicopters than pretty much every pilot, but that still doesn't mean I can safely fly one. Nor does it mean I'm incapable of safely flying one. I just haven't learned the practical skills.

Same goes for system administration, especially if like me you use a different operating system at home than at work, and are developing for a third, embedded, operating system. Sure, I can and do install the software I need for my work, but I have no idea of the best practices to protect against malware and other threats, maintain backups, and maintain a consistent configuration across hundreds of computers in a Windows enterprise setting. I could muddle through, and it wouldn't take long to become competent if I had to, but it's simply outside of my purview and interest right now. I won't insult those for whom it is in their purview and interest by pretending it's possible to become competent at their job without even trying.

Re:You damn well should

[HikingStick]

You hit on a major point. I don't know of any IT help desk or Tier II group that want's to be responsible for installing multiple packages, often multiple times a day. Where major headaches come into play is when, along with the "no admin rights" mantra, you get execs who start chanting "approved software packages only". This works fine for the typical desk drone, but it does not work for most developers, or even for some power users in other industries (e.g., CAD designers in manufacturing). When you start forcing every install to be reviewed, tested, approved, and installed by IT, you have a recipie for a never-ending traffic jam. Developers who are on a deadline can't wait a week until the IT support folks have time to come and install one debugger or supplemental tool.

Re:You damn well should

[MightyMartian]

That's not an example of a developer who doesn't understand OS concepts. That's an example of a moron who should be shown the door with extreme prejudice.

Re:You damn well should

[ThrowAwaySociety]

Wow, what a bunch of morons. In addition to hiring people that understand you just can't do that kind of stuff, my company has controls in place to prevent it. Want to reboot a production server? You need a change ticket, approval and you're going to be doing it during the maintenance window unless it's an emergency. Gotta do it? Call it an emergency and explain yourself later. Can't? Find another job.

Nobody is talking about production servers. Not even testing servers. We're talking about developers' own workstations, and possibly development servers.

If your developers can't be trusted in their own environment, then you need to find better developers.

Re:You damn well should

[bwcbwc]

WTF? It IS a developer's job to worry about system security from an application implementation perspective. It IS a developer's job to understand the operating system well enough to understand the best way to use the operating system's APIs and services. It IS a developer's job to understand what software is on their system, because that software could be interacting with the program they are developing. This knowledge alone makes them more competent to administer and manage their own PC than your typical COE support person. On top of that, they need the access to do their job.

1) Developers should have local admin rights on their machines
2) Apart from automated software updates for standard anti-malware and office tools, the developer should install and maintain the tools required to do their job.
3) The developer should not require access to the normal helpdesk support for issues local to their PC.

On the other hand, as posted below, there is no reason a development machine can't be isolated from the local network, or else the local admin rights can be granted to a local-only user that does not have access to the network. If your company doesn't want to provide developers with two separate computers, limit the network access to a non-admin user. Under *nix, Vista or Win 7 the developer can sudo or invoke the local admin user to install software and perform administrative tasks required for software development.

Heck you can even force developers to develop inside a virtualized environment in a VHD image, but they'll still need admin rights within the virtualized system. Your testers, even moreso.

Re:You damn well should

[Daishiman]

Because knowing OS theory doesn't make you an OS specialist dedicated to implementing good practices on production systems. Even a kernel dev might not know how to install and deploy a production system and implement all backup, user, and processing policies.

Re:You damn well should

[mcmonkey]

Wow. The scariest part of your story is people think this guy is a top performer.

Now, on the one hand, you can say he was very competent in operating his workstation. He knew how to install software. He knew how to configure said software the way he wanted. He knew how to change OS settings to make sure his software worked the way he wanted. He did all this without having to contact anyone else for support

Really? So 1) he owns the company? Or is the president or CEO? If not, why the fark should the world revolve around the way he wants his system to work?

2) Why is it a good thing he can get his system to work the way he wants, when he wants every hacker on the planet to get in to your company's systems through his laptop? And if that's not what he wants, then his software is not configured the way he wants.

Seriously, this guy is a menace. I can grab a chain saw and rip open someone's chest, that does not make me a competent heart surgeon. Yes, this guy made changes, but in no way should anyone say he is competent in operating his workstation.

Re:You damn well should

[Roogna]

And a developer that would make those choices when installing software on his machine, is -also- a developer that will leave wide open holes in the software he's developing for you. After all, he's obviously straight up lazy. So all I'm getting from this is that while he put out more LoC than your other developers, they were most likely buggy insecure junk.

Re:You damn well should

[Anonymous Coward]

As a case in point, here's an example I dealt with a while back. One of the best developers in the company was having issues with Remote Desktop on his XP machine. He got tired of it, so he installed VNC server instead, so he could remote into it from his other workstation. And he set it up without a password, because he didn't want to be bothered to enter it every time he connected. And in order to get it to work, he disabled Windows Firewall. Oh, and this was a laptop, that he occasionally took on the road and connected to public WiFi, like in hotels, airports, and such.

I think this is what Deorus was referring to. If a developer does not understand the implactions of the changes he or she is making to the system (including disabling the firewall), then they are likely to be lacking in the understanding of how their code impacts the systems it runs on. If the application touches the network, then the level of understanding needs to now include a lot more than simply how to compile the app without errors.

Re:You damn well should

[curunir]

I think you've somewhat correctly identified the what while incorrectly attributing it the the why. As a developer, I have less fear of changing things or breaking things not because I feel that things should work in the way I expect, but, instead, because I have confidence that I can fix things if/when they become broken. Sometimes it takes some Googling, but I can't think of a time where I wasn't able to fix a software issue. This mentality applies not only to maintaining a system, but also to doing our jobs. Refactoring code is quite often an exercise in breaking it and fixing it in a more correct fashion.

So yes, I think we're much more likely to fiddle with settings and in the 95% case where it does what we expect it to do, no one notices. But that last 5% of the time where something unexpected happens, our minds are conditioned to work through the problem and fix it. We're not the email/web/office users who get scared when things stop working as expected. We're the ones that, in that situation, get curious as to what's going on and see it as a challenge to overcome.

But the one thing I can say with a certainty is that when restrictions are placed on my ability to maintain my own machine, I suffer far more down time in dealing with those restrictions than I do when I have complete control. It's why I won't work in a large, corporate environment anymore.

Re:You damn well should

[Anonymous Coward]

[H]ere's an example I dealt with a while back. One of the best developers in the company was having issues with Remote Desktop on his XP machine. He got tired of it, so he installed VNC server instead, so he could remote into it from his other workstation. And he set it up without a password, because he didn't want to be bothered to enter it every time he connected.

He doesn't possess a lick of sense. The kindest thing would be to take him out back and shoot him.

Seriously, if this is one of your "best developers", you have Real Problems at your place.

Re:You damn well should

[nine-times]

Well of course I don't literally believe in "computer gods", but on the other hand I think superstition sometimes gets a bum rap. Is it bad luck to spill salt or break a mirror? If you live in a society where mirrors and salt are expensive, then it sure is. Even more so with breaking mirrors, since it leaves little shards of glass to cut your feet on. It's also a pretty idea to walk under ladders, given that you might knock it over (hurting the guy on the ladder) or the guy on the ladder might drop something (hurting you).

My point, really, is that sometimes your knowledge isn't as important as your habits. If you know why you shouldn't walk under ladders and you do it anyway, you're more likely to get hurt than if you just don't walk under ladders because you think it's bad luck. Similarly, if your IT guy says that a certain computer "doesn't like it" when you do a soft reboot, then you might just want to go ahead and do a hard reboot. Maybe he's being superstitious by anthropomorphizing the computer, but that doesn't mean his advice is bad.

Re:You damn well should

[Anonymous Coward]

Dude that is TOTALLY contradictory and if you can straighten it out the rest of the class would like to know how...

You go on a rant about how it is important to do. Then turn around on a rant on exactly WHY you need to trust your help.

This company I currently work with I have been there for years and already have the privs I need. But we just hired a new guy. Extremely good at what he does (having worked with him before I know this). However he hasnt coded 1 line of code in 2 months on his 'real box'. He is waiting on management to decide he can have dev programs on his computer. Just last week he finally got the privileges to do it. My direct management is NOT happy about this. And well they should be right pissed off about it.

In the mean time we gave him an unmanged computer to do his work. This creates a natural 'grey net' in the real network. Having managed my own networks in the past 'grey nets' are the worst breeding grounds of worms and viri. As they are always out of date as the people setting them up forget to update them (yeah you know that VM you set up 2 years ago with the copy of NT4 on it and no virus/firewall/updates on it). When IT is in the way of getting things done IT is the problem, creates a 'we vs them' mentality, and creates a computer management nightmare. People will work around the problem. One place a friend of mine he 'worked around the problem'. He got shown the door. Companies that put these policies in place are saying that the policy is more important than getting work done. I am not saying policy is unimportant. But you can go overboard with it and eventually your workers either walk or work around it.

Re:You damn well should

[NocturnHimtatagon]

I have to use a kernel debugger for my job as a developer (The brown-out wasn't working). Security is gone by adjusting a register.

How about this: I won't do this on production server or whatever machine that's critical, and you leave me to do my job.

Re:You damn well should

[keean]

If the developer does not understand basic computer security, then their code is probably full of the same problems. To write secure code, you have to understand security.

Yes, because I'm not a masochist

[Knara]

In the Windows world you can override other things using GPOs, but it's too much of a pain from the admin side (I've found, as have my coworkers over the years) to try and lock down developer machines by removing local admin rights. I've got better things to do than schedule up a time to install things via an account with local admin rights every time something new comes along for them.

The flip side is that they have greater responsibility for maintaining their desktop/laptop systems. If it gets screwed up enough, they know they're getting the thing re-imaged with the company standard desktop image and will need to reinstall their tools they use for their personal dev environment.

Works out pretty well, aside form the devs that install absolutely everything they come across, "Oooh that looks cool! [installs][never uses again]". They can be a pain.

Re:Hell no.

[JohnFluxx]

What has that got to do with LOCAL admin rights?

Conflict of interests

[node159]

LOL! Giving developers admin access to production machines is like giving grenades to babies, its only a matter of time.

Ultimately it comes down to a conflict of interest between developers who's interest is to changes things (new features, new version, etc) and admins who's interest is not to change things (SLA's, guaranteed uptime, don't touch a working system).

If this conflict is not properly balanced (dev's with fingers in production, admins controlling the dev environment), you will have problems and usually ends up being a very costly mistake.

Re:Conflict of interests

[node159]

In addition, as a developer I NEVER want to know root passwords for production systems, as this only means two things, support calls and being on the short list for the which hunt when something enviably goes seriously wrong. There is nothing quite as cover your ass as 'I never had access'.

"Standardization"

[Nerdfest]

Organizations that treat developers like standard "business" users are going to get systems developed as well and as fast as those created by standard "business" users. A developer needs at least elevated rights on a workstation.

Re:Under no circumstances

[bigstrat2003]

The key word was local. He wants to know if he should give his developers admin rights on their machine, not to the entire network like you're talking about.

What it REALLY comes down to

[Anonymous Coward]

Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally. That's the entire problem. The entire design of windows is to install **** under system32 or program files when it doesn't need to be there. I remember the old days when programs ran under one directory. Easy to maintain. You know where everything is. To uninstall is simply to delete. Don't get me started on the registry. REALLY? You're telling me it's "faster" than reading a text file config. Hardly. ARE YOU HEARING ME MICROSOFT? Why the **** do you even need admin rights? YOU DON"T!!!

Re:What it REALLY comes down to

[Anonymous Coward]

It's okay, you're allowed to swear on the Internet.

Re:What it REALLY comes down to

[bakuun]

Here's the thing... Why the **** does windows program installation basically require files be installed any place other than locally. That's the entire problem.

For the same reason that most other operating systems, including most flavors of linux, requires admin rights to install software. There are reasons that you want the operating system to be aware of when software is installed. One good advantage of this (in the Windows world) is the add/remove programs section under the control panel, where you can view all installed software, how large they are, and easily uninstall any of them. Another advantage (this time from linux) is system-wide updates of all installed software.

The entire design of windows is to install **** under system32 or program files when it doesn't need to be there. I remember the old days when programs ran under one directory.

Yeah, one directory, like... "Program files"? Every program installs to Program files by default, although the user is free to change this of course. How does it work in linux? Well, if you install something parts of it can go in /usr/bin, parts go in /etc, parts in /usr/lib, some in /var/.../

You know where everything is. To uninstall is simply to delete. Don't get me started on the registry. REALLY? You're telling me it's "faster" than reading a text file config. Hardly.

I don't know if it's faster - it might be, or not. It probably doesn't matter a great deal anyway - it's not like it's a lot of data. I doubt it's slower, though. The windows registry is a hierarchical system of configuration settings (with parts that are global for the machine and parts that are local to the user), and /etc is a hierarchical system of configuration settings (contained in text files)... Where's the big difference?

yes

[pak9rabid]

The entire development team where I work has full admin privileges on their local workstations. Not giving them that would be disastrous for productivity...

Yes in DEV, No in TEST and PROD

[garyisabusyguy]

It is a huge pain in the ass to do development without local admin rights.

HOWEVER, it is a huge cluster fuck to implement in PROD because your permission levels all have to be reconfigured to fit any rational security model.

I have found that denying developers local admin in the TEST environment is a good way to shake out any implementation nightmares

Re:Yes in DEV, No in TEST and PROD

[cayenne8]

Hmm...what are these DEV, TEST and PROD environments you speak of?

Hehee...honestly, and a LOT of this was govt work, so many (I'd dare say MOST) projects I got onto, you basically had one box they gave you, you developed on it...and when it got to a working state..voila!!

It then became the production box.

The lesson I learned from this? Make damned sure to order the most amount of hardware you can on a govt/DoD project, cause you likely won't get any other boxes anytime soon, even if they promise them to you when planning things out at the beginning of a project.

At least...that has been my experience in that world.

That's what sudo is for

[tepples]

if the developers have to develop for a multi user and limited rights user OS they will actually build software that obeys those constraints.

That's why you use an OS that has a counterpart to sudo, like Windows Vista, Windows 7, Mac OS X, or Ubuntu. You'll still get "permission denied" for apps that you develop, but you still have the right to elevate to run an installer.

Re:virtualization

[RingDev]

Just what I want to do... Run 3 IDEs, a SQL authoring tool and database explorer, a web browser with 5 tabs, fiddler and other debugging tools, all inside of a VM running on a 3+ year old 32-bit computer with 3 gigs of memory.

-Rick

Conversation with the company's head IT admin

[PinchDuck]

"You know the company policy, but now I will ask you directly: Do you have any software on your computer that I have not personally reviewed?"
Yes
"WHY?!?!"
Because I write it. It's my job, and I don't have time to submit every program I write to you for approval before I install it on my machine to test it.
Admin Draws deep breath...
"AND...that makes sense. OK, you can have admin privileges on this machine".

I know places that don't give their devs admin privileges. It makes their jobs much harder. Security has to make sense to keep a corporate network safe, not to inconvenience everyone or make their jobs harder.

Re:What?

[Javagator]

as an admin, I prefer to maintain control of what is installed on the systems

That's the way it always is. The admins want to limit control to make their jobs easier, and the developers want full control to make their jobs easier, and never the twain shall meet.

Re:What?

[pixelpusher220]

actually it's usually about the manager's making *their* jobs easier. Having to explain why you need 2 machines (1 prod/1 dev) for a developer and 2 separate networks that need to be segmented and separately secured with separate configurations let alone the expense involved tends to get a big fat 'no' from mgmt. "Just do it the quickest and cheapest you can".

An Admin is well within his rights to maintain control over what is installed. Remember all the inadvertent leaks of documents because a user installed some file sharing program? That's an admin who didn't have, or wasn't allowed, adequate control over systems under his umbrella.

Developers DO need full admin rights on their dev boxes. You *really* don't want to be bothering the admin teams with "hey I need to restart IIS and/or reboot my machine" every 15 minutes if you're troubleshooting something.

the proper solution is separate networks where the developers simply can't cause significant damage by having admin rights. Unfortunately as has been said above, it's just easier to give developers admin rights on their systems without them being on separate networks from production systems.

Re:virtualization

[RingDev]

I have 3 IDE's open because most of my work is front end stuff (AJAX/Silverlight), so I'll usually have VS2008 and Blend 3 open. Then if I need to be working on back end services, I'll have another VS2008 open for that. And invariably, someone at some point in time during the day will swing by with a question, debug request, or something else for another app, so I usually wind up with a 3rd copy of VS2008 or VB6 open.

For our SQL Server stuff I us the VS2008 server explorer, it handles most of the basic functionality I need, but not views, nor the AS400.

For the AS400 we have a custom .Net app that gives full intellisence, meta data searching, and descriptions in a traditional SQL+ like interface. So if I'm working on anything that hits the AS400, that app is open.

-Rick

Re:What?

[multi io]

Developers DO need full admin rights on their dev boxes. You *really* don't want to be bothering the admin teams with "hey I need to restart IIS and/or reboot my machine" every 15 minutes if you're troubleshooting something.

Why would you need admin rights to restart IIS? I did Enterprise Java/J2EE development on SunRay X11 terminals for some years, never had admin rights on the connected server (X11 client) machines, and still regularly restarted and even installed and updated complete multi-tier Application servers, of which the web server was only a small part, in my home directory... Now I wouldn't say that that was an ideal development environment, but I rarely missed admin rights. In fact, if you think about it, there aren't many things that are intrinsically "admin-only". Installing software or restarting server processes should not be one of those things.

Re:What?

[syousef]

That's the way it always is. The admins want to limit control to make their jobs easier, and the developers want full control to make their jobs easier^H^H^H^H^H^HPOSSIBLE, and never the twain shall meet.

There fixed it for you.

Re:What?

[dvice_null]

"worked best for me"? I'm sorry, but isn't your job to support the others and make their work easier, not the other way around? Obviously you should make your own work more efficient, but not in the expense of the others. So are you sure your solution has not harmed anyone? "It took some getting used to" sounds like harm to me.

Re:Virtualization is your Friend

[zzyzyx]

The argument that they need to do things that "really, really" :-) require access to the bare metal, doesn't hold anymore, because the applications they are building will anyway need to be able to run in a virtualized environment.

Why do so many admins seem to think that you don't need more tools to develop an app than to run it? You may not need that screwdriver to run your car, but you really do need it to assemble it.

Re:Nope.

[bingoUV]

What if the developer is developing that very server? And it needs admin privileges to restart?