Can Developers Work in a 'Locked-Down' Environment?

brad-d queries: "My company is seriously considering enforcing a SOE on all employee computers, including developers. The level of lock-down would likely include baring the Windows registry from changes (and in effect stopping the installation of new software). The goals of this SOE are to prevent users from installing unlicensed software, plus some support issues. What are others experiences with situations like this? Can a developer really work in a lock-down environment? What compromises could be made between developers and IT services? And no, Linux would be likely banned." It depends on how "locked-down" said environment is, and what the developer would be will be working on, however if the Registry is locked with no mechanism provided for the Developer to add in whatever keys are necessary, how much real developing can one do?

Comments

Registry lockdown?

[syates21]

If all areas of the registry are completely "locked down", I don't even think a lot of *existing* application would run, let alone installing new ones.

No, you can't.

[dmorin]

Easy question : no. My group has our own Unix boxes and our own support group for most things except DNS changes and stuff like that and we still run into inefficiencies in getting routine things done on time. We do not have administration rights for our NT desktops in the sense that we can bring in our own OS upgrades, but we do have the freedom to install new applications. I can't see it working any other way.

If whoever is thinking about making such a decision is in charge of development, then get your resume in order because if I were you I wouldn't want to work under him much longer.

Re:No, you can't.

[ladykadyj]

I would wholeheartedly agree with dmorin. I think it's perfectly valid to have a development department in charge of their own "space". I've worked in that environment very successfully and at the satisfaction of both the development and IT groups. They stayed out of our way and we actually helped them with some of their problems.

I've also worked in an environment where the implementation group controlled everything (this was just when SMS came out, I still have the shakes), your computer was set up for you, they periodically came around and uninstalled screen savers and whatnot... but imagine monday morning when you come in to work and your computer gets the BSOD because some nitwit from tech support messed up your registry when ensuring your computer was "compliant" with corporate policies, or they screwed up your file links and now gcc can't find your mysql header files because you had a "non-standard" installation... Occasionally they would allow us to make the necessary changes ourselves if we were buddies with the technician -- let's face it, I feel more comfortable in my abilities to maintain my computer, I use the thing every day for crying out loud!

I can understand the IT department's headaches from users who screw up their machines, but developers are typically smarter than the average Outlook user (hopefully??) and can manage their own computers just fine. Computers as company property and subject to coroporate/IT policies is one thing... coding with my wrist chained to the chair is another.

Freedom is not for the ignorant.

Trust?

[Nick]

If you can't really trust your developers, and need some restrictions in place like that, then maybe you shouldn't have them working there in the first place?

They can't

[well_jung]

We faced this issue when standardizing/locking desktops during our upgrade to Win2000. The only workaround that was agreeable to both sides (developers and IT) was to allow developers to have free reign, but not to expect anything more than "We can re-image the machine" from IT when said developer screws up his machine.

If you get out a bible and swear to IT that you are willing to not ask for support when you screw shit up, they may be open to letting you be blessed.

Re:SOE?

[Gill Bates]

(guessing)
Standard Operating Environment or
Standard Office Environment

Not Enough Information

[pmc]

As the sort of person who designs these policies I have to say that there is not enough information to give you an answer, so if you don't mind I'll illustrate with a few principles that I work to.

Surprisingly enough, nobody implements such a policy because they are evil incarnate - you may not believe this, but it is true. The reason that policies are setup like this is purely to save money. And the money is saved because a huge proportion of support time is spent fixing PCs that users have wreaked because they've installed that cute new application.

This leads directly to the BOFH approach to policy - nail it down, and nail it down hard. Don't even let them log on without a letter from the Pope. This is a stage one policy. Support calls drop dramatically, user productivity is zero.

Now, a bit of reality is introduced. People have to use their machines, so against our better judgement we let them log on. And print. And even save things to the hard disk. This is stage two: most people can do what they have to do, support calls rise a little.

Then you deal with the exceptions. Depending on the type of user the general restrictions are lifted. There may be strings attached (such as the screw up and we'll only reimage) or maybe IT will arrange proper support for the application etc.

The point to remember (and so many people forget, especially people in IT) is IT support is not the business. If you are in the business of making widgets, or writing code, then IT support do not do this - they exist to help you do this. They exist solely to allow the business to function more effectively. They are "facilitators" (to use a horrible word). They provide a service.

If that service prevents the business doing things that are required for the business the the service is substandard and needs to be replaced. In this case that service is a policy, and it need to be replaced. I have designed a policy for devolopers, and the policy is

1. You get a standard PC with the standard loadset, and admin rights on the local box.

2. If you screwup we will only reimage.

3. If you repeated screwup we will still reimage, but we will start charging you.

4. All software to be purchased (if costware) and registered (registerware) via {specific person}.

Lockdown policies are loved bu IT departments, but if it stops you (or anyone) doing legitimate work then it is broken and needs fixing.

Locking down makes for useless development

[hyrdra]

A locked down system is as useful as a tool as a hammer is if it were barred from making marks in it's head.

Clearly, the process of developing suggests an errorenous progression; changes are made gradually. With the inability to make changes, one loses the ability to develop.

Most companies have a locked down test system, which serves as a scientific control, but having a locked down system for which to work and develop would yeild an environment where very litte work could get done. You need to be able to change a system to make something, its as simple as that. Imagine being requested to build a new house, or better the foundation of said house if the ground couldn't be touched.