Slashdot Mirror
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?
I'm just at the end of a six-month contract to put together a PHP/MySQL/Apache based website, in a locked-down Windows 95 (!) environment with a few thousand users.
They're migrating to W2K shortly, but I put my foot down and they allowed me to wipe my box and install RedHat on it -- the only way I managed that was the fact that it was in a nice shrinkwrap box.
Well, all fine, but I get no support and I'm not allowed to put it on the network, so it's sneakernet for me. Access to the internet is done with floppies. =(
The point is that you may be able to persuade them to let you have a purely standalone machine, as long as you keep an SOE machine next to it for running Outlook =)
This is just an idea off the top of my head. But would your company be apposed to the idea of having a developers lab that would be off the corporate network. This lab would be sort of an anything goes environment, where developers could mess with things such as what ActiveX controls are installed, keys in the registry, and what component versions live on the box (anybody familiar with ".dll hell"?). If the developers screw something up, it's up to them to fix it. The IT support staff wouldn't have to be involved at all.
Where I used to work at we had something similar called the time warp lab, that had a bunch of machines running different versions of windows with different components installed. The developers could test their code on them, and when we were done, we just ghosted a new drive image onto the drive.
Check out my podcast: DreamStation.cc Video Game Show
They will run... but you'll get errors all over the place. In my college the C: was read only. You could only write to d:. It was annoying, but i am sure cut down loads on the IT bill, and stoped too may mp3 servers running.
Cruise TT
When I was in the Air Force we ran into the same situation. All of the MS boxes that were connected to the Lan were locked down to the extreme that you could not change your background and even the file manager was locked out. (only 2 of our development machines where on their network btw)
After we received a request for an email tool we bitched and bitched about getting the rights to load it on a networked PC as well as SOME info on how our Mail servers worked. They said no so we delivered the product as is. Surprise of Surprises it didn't work right.
We the programmers then got all the rights back that we had before. All it should take is some truly crappy releases from your developers before they give you back at least some of your user rights.
Just make sure that you document all of your hassles before you release it:)
..which just shows that the human brain is ill-adapted for thinking and was probably designed for cooling the blood-T P
Since I'm responsible for "corporate standards" for a big conglomerate, I'll try to answer from the perspective of "The Establishment".
Unfortunately many companies don't house full-time developers and instead prefer to outsource on a per-project basis. Because of this many of them are concerned only with making their app run, at the expense of others. ie - Develop an app that's dependent on IE 5.0 despite the fact many company sites only work under IE 4.0. Bad code all around, eh?
This leads many companies to implement lock-down and I have to sympathize. In a perfect world all your tools would be installed by your Desktop folk and even your development PC would be locked down. In a more realistic world you would have a more open development platform but all testing would be performed on a locked-down PC. A nice compromise since it affords you the freedom to install the tools you need (I think historically no Desktop support technician has ever installed Visual Basic 100% the way a developer wants it!) while still ensuring you are developing an app that doesn't stomp all over settings and files that other apps rely on.
Also, keep in mind that there is (essentially) no user context in Windows that "locks down" the entire registry. What it does is grant full access to user areas and no access to system areas. The only big difference here between "secure" *nix and "insecure" Windows is that in Windows full control is the default. There's no reason why lock-down has to be a bad thing for a developer. In fact it's often a good thing as it prevents the next developer in line from writing an app that will kill yours.
I write in Java using a text editor and I haven't written to my registry in months.
In fact, when I first got here my system was locked down like a prisoner by accident (they thought I was an intern...god I hate being young) and I didn't notice for four months, and then only because I installed JDK 1.3.1 (which wanted to change my JavaPath).
Yes, Java CAN interface with the registry, but it's a heck of a lot easier to use object dumps and ini files (in xml of course). And since things don't need to be "registered" (more trouble than it's worth) due to the namespace and classpath, you end up with a very nice sandbox development environment.
I wish this effing COM object I've been trying to teach how to use the network all morning were written in java...
Hey freaks: now you're ju
we gave up on locking down and went back to rebuilding the systems nightly...
When I was attending Purdue in the mid '90s, all the computer lab machines would reload a disk image over the network after every reboot. It only took about 10 - 15 minutes to get a login after starting a reload, and you were guaranteed a completely fresh environment. It sucked if you only needed to print out a file from a floppy for that class that started three minutes ago. On the other hand, you never had to worry about malicious code. No viruses, trojans, password sniffers, etc. It made maintaining the machines that much easier. Each lab had its own master image and any updates could be tested on an admin workstation before the updates were published. Once the image was published, every machine was updated at the next reload.
the company will be unnamed, but it is multinational and deals with lots of $, so such a system is not merely an issue of overzealous, over-anal management, but one of government standards and important security. in said environment, development can be frustrating. here is how i adapted.
;-) it is very frustrating to develop on a box you don't even have rights to the C: drive on (the case here). but, in a strange way, it makes you write code and think of apps in ways you didn't before. that is, stateless, no need to touch the registry at all. i know, this is impossible for some apps and i am talking theoretically here. but rather than store registry cookies to identify users and preferences, etc., why not identify who is using a computer by identifying who's logged via standard function calls, for example, and have all their preferences stored on some distant database? be creative. there is always another way than what seems to be the only way. wax on, wax off, danielsan ;-P
;-)
1. tiny apps. just like the recent post. since single executeables do not need to muck with the registry to run, you are able to utilize small powerful ftp clients, html editors, etc.
2. build your own box. i put my case to my manager's manager, and they made an exception for me. i had (until the sept 11 wtc disaster, in which my workstations were turned into crispy critters) 4 computers at my desk. two were standard company-wide locked-down builds, and the other 2 computers they let me install nt server from scratch. nt security just made sure they had admin rights on them in case the box did something not quite right. then of course, software support washed their hands of these boxes. i had to install my os and software, i had to maintain it. if i screwed something up on the box, it was all for me clean up. which was fine for me, i'm a developer, i can support my own box. i want to support my own box!
3. write stateless software. change your paradigm. become one with the great zen of concise programming for the wrong reason: not because you should, but because you have to.
other tip: depend on nothing. my profile with it's personal settings blows up from time to time and is reset to the generic sucky settings and i have to personalize all of my standard apps all over again. after awhile, i made sure not to put too much faith in leaving my desktop and depending upon it to look the same the next day. batch job important standard settings to rejigger everything (drive mappings, odbc connections, etc.) in cases of nt alzheimer's.
finally, there's no getting around it, a locked down SOE sucks for developers. developer= power user. developer= someone who HAS to muck around with things regular users don't. so bring this up with management. you guys are special, obviously, the most thick-headed manager can see that. maybe, before they SOE everyone, you can convince them to firewall all you dangerous developers in your own domain and let you hack your installs to your hearts content, unsupported, insecure, untrusted, but necessary to build apps.
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
For that matter, you also need to be able to prevent IT from automatically installing 'upgrades' to the software.
A few years ago, we had what we thought was a rigorously controlled machine that had the minimum revision levels of the O/S that our applications were supposed to work with. This machine was used for testing and for building the final distribution of the application.
A few days before building a production version of the app, IT used their domain adminstration ability to add a simple 'run once' item to the machine to do a simple service pack installation. Unfortunately, this was not noticed in time, and when we logged in to do the shipping build - Did you know that some Microsoft build environments automatically make the application require that the target machine have at least the same or later version of all DLLs and COM components as the build machine?
So we shipped the app suite to the beta customer sites, the installation runs fine, but the apps all complain about missing DLLs and components.
Of course, the IT domain adminstrators no longer have administration privileges on the development area boxes - and now we have our own development domain. Central administration (from outside the department) and a properly controled development environment both require absolute control over machine configurations - but the development department needs multiple configurations. The two versions of control are incompatible. And that's just for test and build machines.
Even if you are developing in Java, you might not get the same results from two different JVM versions (if it's Microsoft JVMs you will, anyway).
Final answer? Let IT control machines that are used for IT functions, and let developers control machines used for development functions.
Liquor
Sanity is a highly overrated commodity.
I work for a large software company. No names, but we're talking over $1B in cash on hand, and we probably have as high a percentage of employees who are software developers as any company. As a general rule, developers don't go to IT with problems until they've run out of options. I have a separate IDE hard drive with a ghost'ed image of my primary machine that I've used on several occassions to save my ass and get back to coding when I don't have time for some IT clown to spend a day looking at my machine and then deciding to rebuild it. Personally, I would be about as effective as a chocolate fireman if I had to work within the type of constraints you've defined. I waste enough of my time as it is getting around barricades put up by IT.