Is locking down a developers machine more effort than its worth? [closed]

Having worked as a developer and in IT admin/support for a development team, I've come across many different types of environment from the completely locked down to the completely non. In my limited support experience I think its been less effort to support with a less locked down machine and I certainly felt this was easier, but of course this could be bias. I'd like to know what the view is from an IT support perspective, is it genuinely harder to support developers who have non locked down machines?

The biggest problem with not locking down a developers machine is that any software they develop will require full administrator privileges to run. The developers access should be the same as the environment that they will need to run in. If they need to be "self supportable" or "self installable" then give them another admin account e.g. Bruce.admin which they need to use when doing admin stuff, but not used day to day.

Just like no decent UNIX admin worth their salt will ever use a root account for their day-to-day non admin work.

Most developers are technically savy and know what they are doing. They often need to install many specialist apps, having to get permission to do this and getting IT to come down and add it can be very frustrating, particularly in larger companies, for both sides.

I've found what works best is allowing them to do what they want with regards to installing software on their machines, but if they get into problems with something we don't support, then they are on their own. Most developers are happy with this, and prefer being able to look after their own machine anyway.

Locking someone down in accounting to only use IE and open word is fine, but if your a developer who needs to install 4 different types of browser and need to quickly install an app to solve a problem, it can be annoying.

My experience is that companies who have alot of technical knowledge, so development shops, IT suppliers etc, who trust their employees and let them decide what they want installed are much happier and bother IT less

See this Stackoverflow posting for some lively debate about the merits of locking down developer machines. (Disclaimer: I wrote the accepted answer).

From a sysadmin perspective, access to production systems is sensitive and you should restrict such access to people who need it to do their job (this may include developers who have tier-3 support responsibilities for the application). Local admin rights over a development PC or development server does not significantly compromise security of your production systems.

Make an image that you can use to rebuild the machines with if necessary. Manually installing SQL Server dev edition, Visual Studio, Cygwin and MikTex plus a bunch of other apps is quite time consuming. An image with these large apps installed will be reasonably valuable if you have to re-image the machines much.

From a development perspective I find that I can fix most problems with the machine and typically only need help from network support staff on fairly rare occasions. Overly restrictive environments tend to generate spurious dev support traffic to do work that the developers are perfectly capable of doing themselves.

Another place where developers tend to need a lot of admin work done is on database servers hosting development environments. Most developers are capable of learning routine DBA tasks easily, and should get a working knowledge of this anyway (IMHO on principle). Overly restrictive admin access policies on development servers can get underfoot in many ways.

A scratch development network is quite a good idea if it can be arranged - you can firewall this from your production servers if necessary.

• When developers can easily replicate the structure of a production environment it promotes a culture of deployment testing where an integration test can be synthesised without jumping through hoops. This will tend to improve the quality of production release and deployment.

• Being able to emulate a production environment also raises awareness of production deployment and support issues. It encourages development staff to think of how an application might be supported in production, which will probably encourage architectures built with this in mind.

• If this network has a domain controller you can establish a trust relationship so it trusts your main domain controller and its accounts. This trust relationship does not have to be reciprocal, so it does not compromise security of your production network infrastructure. This can let you have an untrusted development network but still allow developers access to domain-authenticated resources such as Exchange accounts or file servers.

• You want developers to have a reasonable amount of scope for experimentation without having to jump through hoops. Placing political obstacles in the path of this work has a tendency to encourage sticking plaster solutions that are politically expedient but generate long-term (and often unrecognized) technical debt. As a sysadmin or support analyst, guess who gets to pick up the pieces ...

I will add that this is much less of an issue on a unix or linux environment; users can pretty heavily customise their own environment from their .profile. You can compile and install things under your own /home/bloggsj/bin directory to your heart's delight. 'Local admin rights' is mostly a windows problem, although there are still a few things that need root access under Unix.