Can Developers Work in a 'Locked-Down' Environment? 648
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?
Registry lockdown? (Score:3, Insightful)
No, you can't. (Score:4, Insightful)
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.
Trust? (Score:3, Insightful)
They can't (Score:5, Insightful)
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.
If they insist (Score:2, Insightful)
Eventually they'll realize that the price they're paying in increased support calls is not worth the "security" of locking down your desktop.
I'm in just such an environment. Less than two weeks and they gave me local administrator priviledges under the table.
Re:SOE? (Score:3, Insightful)
Standard Operating Environment or
Standard Office Environment
Re:No, you can't. (Score:5, Insightful)
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.
Not Enough Information (Score:5, Insightful)
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.
And the complementary question is.... (Score:2, Insightful)
Can a production environment really work if developers are given complete freedom?
Where is the line drawn between freedom for developers and ensuring a stable, consistent and cost controlled environment? Granted freedom is needed to evaluate new tools and techniques, but shouldn't this be within the bounds of a defined framework? (If the answer is no, then I guess all the NASA source code discussed in a prior article today must be considered the product of luck.)
Childishness and business are incompatible... (Score:1, Insightful)
I work as an I.T. Director for a medium-sized web development company. I tried letting the developers have admin rights, and it ended up a nightmare. Each dev wanted his/her own text editor, own IM client, special this, special that, to the point that no two dev machines were alike. They were completely unserviceable from an I.T. standpoint. And when a developer wanted tools we didn't have licenses for, well, THAT DIDN'T STOP THEM, they just downloaded a warez version and used it anyway. I.T. would only find out if there was an audit. Policies were ignored, and email pleas to just keep I.T. informed of system changes went ignored.
I got news for you kids out there who think being a developer is like being some Picasso or something: wake up. You're in a business, and if you don't like it, you should file for unemployment. If you create a software violation, people like me in I.T. have to answer for it when MY PHB asks why I allowed this to happen. *I'M* on the line when some stupid developer downloads the latest beta of some neato-keeno tool that ends up compromising the corporate firewall, or flooding the network with spurious traffic, or screwing up the code management systems.
I fixed the problem in my company quite easily: I said I'd be absolutely happy to relinquish admin control to the developers if they could just prove one instance where they couldn't perform their JOBS without these admin rights. No one could make that case, although plenty bitched about not having AIM, ICQ, or Realplayer to play around with. Needless to say, they didn't get admin rights. Development still got done, projects got finished, and the devs got over it.
If there are any I.T. people out there, stand fast and don't put up with crap from developers. They seem to think they're above everyone else out there. Make them prove their case before giving them something that you KNOW they'll abuse.
It depends on the type of development to be done. (Score:2, Insightful)
On the other hand, if you're doing bleeding-edge work, or writing hardware drivers, or developing system software that needs to perform privileged operations, then you really can't do this. Or, even if your development work doesn't _strictly_ require root/administrator access but you nevertheless want to maintain a creatively charged group - i.e. if you want to write a killer app that will change the world, and you need people who are as much visionaries as they are programmers - then you absolutely must work hard to remove all barriers to accomplishment from their environment. (You must also remove any sharp objects or dangerous items; for example, scissors, staplers or any access to production servers.)
In practice, the majority of development shops need more of the former, less of the latter. But in the cases where you do need visionaries, you really need them. And they are very hard to find, very hard to keep, and very very hard to keep focused on a task. The last thing you need with these people is another headache, so just let them do whatever with their own machines and hope to hell nobody ever audits their licensing compliance. Try to remember that if you can't get a straight answer out of them, an external auditor will most likely be totally baffled. You can hope, anyway.
If you make your money in something other than software, and your programmers act like prima donnas, get different programmers. Internal-use software development never requires this kind of visionary status. Whatever your current staff may be telling you, you can build a decent development team using nine-to-five, do what they're told staffers. And you can do it with locked down boxes.
-Graham
The customer's always right! (Score:2, Insightful)
BOFH is a good read, but try it and everyone will hate you. Then they'll hand you a pink slip.
Our policy is to allow everyone, (even secretaries) local admin rights on their boxes. We give them network shares for stuff that needs to be backed up. Then we do something novel, like get off our duffs, and train them to use their computers. Some don't get it, but at least they know they can always get one of us to help if they get over their heads.
If you treat your fellow employees like lusers, they'll act like lusers. Expect them to act like professionals, give them the tools and the training, and they improve over time.
And developers? Let them have any tool they can get approved, and help them use it. Otherwise you'll miss out on a lot of cool tech that doesn't necessarily show up on slash... Or is surfing and checking out amihotornot.com more important?
Locking down makes for useless development (Score:3, Insightful)
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.
Ability to admin considered beneficial (Score:2, Insightful)
developers. This assumes you are in a situation where you have free
reign to build / configure your machine - for me it was a tiny Linux
enclave in a mostly Windows and mainframe organization ("you break it,
you fix it - don't bug us, and we won't bug you"), and I was
developing internal software tools and Web applications on free
software (Linux, Apache, Perl, etc.).
The great advantage (for me) of this setup, other than simple ability
to function at my job, was doing the admin work taught me a *hell* of
a lot that was useful to me as a developer. Building, installing, and
*configuring* the kernels (including occasional oddball device drivers
cobbled together off of the net), compilers, libraries, Web servers,
databases, etc. that I used to develop with, having to do my own
networking setup, keeping up with security patches, etc. gave me huge
amounts of experience that I wouldn't have gotten just programming on
a box that someone else set up.
With this experience and exposure, when my boss would wander by my
cube to ask what it would take to design and build some new system to
do X, Y, and Z whether as an internal app or to deploy on our public
Web server, I could usually give her an accurate estimate on the spot
of the effort involved, how much we could use free software for vs.
how much we had to build [funny... there was no problem buying
proprietary software when needed but it rarely was], what could go on
Unix vs. Windows and the size of hardware needed, etc. I never knew
any of that stuff when I used to be a pure code monkey working on
standardized boxes - it was someone else's problem then. So while you
may argue that developers don't need full control over their machine,
I guarantee that they will either learn from it, or go back to letting
someone else admin the machine.
Working with two other developers with the same approach was great
also. I used Slackware Linux preferring to develop in Perl, my team
lead ran Windows NT with a Red Hat box on the side, developing mostly
in Java, and our junior team member ran Red Hat and programmed in
both. By having to share code in an environment like that, you were
pretty much required to use good source code control, keep track of
runtime requirements (libraries paths etc.), and write portable code,
or you would always be pissing off your coworkers.