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?
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.
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.
www.HearMySoulSpeak.com
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?
Fuck Ajit Pai
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.
Carl G. Jung
--
"With one breath, with one flow, You will know Synchronicity" -La Policia
Sounds like the policy implementors are concentrating on making things easier for themselves, rather than making things easier for the people that do the actual work in the company.
Shutting down free speech with violence isn't fighting fascism. It IS fascism!
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 =)
I have a list of tools that I'd consider essential to my development environment. For any new job in the future I'd get, I would just ask if I can have them installed, and tell them why. Specifically, I'd put in terms of my productivity. If I still get a solid no, then tough shit, right? They own the computers. There is no compromise.
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
Since you mention locking down the Registry, you're presumably developing for Windows--but unless you're just writing ASP pages or something, you have to register whatever it is you're developing. That's the Windows model. This sounds exactly like the kind of PHB-think that turns a minor headache (license compliance on the off-chance of an audit) into a major disaster.
Fortunately, it's the kind of policy that's too stupid to stand. We had a similar thing (promulgated by memo from the CIO, rather than enforced at a technical level, though) which held for about twenty-four hours before they quietly exempted all the developers...
That's like write-protecting the entire drive. It's stupid and foolish.
Technically, the default in Windows NT is to allow Administrators access to the registry, but deny Users. But even then, that's talking about the System registry (HKEY_CLASSES, HKEY_LOCALMACHINE etc). They can still access their own registry hive (HKEY_CURRENTUSER). Any time they change a setting like background color or window placement (provided those rights haven't been taken away by a system policy) is saved there.
You wouldn't write protect an entire drive to keep people from messing with the Windows directory. Just block off that directory.
Likewise, the registry has the same kind of access controls. Give developers read/write access to a specific key in HKEY_LOCALMACHINE\SOFTWARE. Technically, this is where they should be storing registry settings anyway.
- JoeShmoe
-- I wonder which will go down in history as the bigger failure: the War on Drugs or the War on Filesharing
I know many developers that do very little outside of what they are told to do. Thus management leads the design process and the developers follow. This leads to people who are not very aware of modern technology designing a 'supposed' to be modern app. With some developers installing new apps, testing new software and doing things like that on their own they would be constantly callin IT for this and that, especially if you have a R&D group. Personally I woudl be against that as I like to install certain of my own favorite editors, icons, tools to make some things I do easier. After that I suppose IT could lock the registry, but ask yourself what does this really gain? IT should just say we support this software and if you install stuff and screw up your machine you just have to wait. In some cases it is just a matter of knowing who can be trusted to know what they are doing in Windos. Some users can install and uninstall and do as they wish and you'll never hear from them while others will be constant problems.
Only 'flamers' flame!
Pester the support people. Make them come out to install every new piece of software that you need to do your job. Hold their feet to the fire for all the support you need.
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.
It doesn't work too well, especially if you are developing software for the PC, to lock down developers.
Most places allow developers to disable the lock-down, and generally won't debug your machine if you screw it up, just rebuild it from scratch. Even the big guys do that.
Gentoo Sucks
2 ways that I have seen.
One. The department is woefully underskilled and incompetent for the jobs they need to perform. In an effort to try and head off as many problems as possible they lock things down to a minimal set of known circumstances.
Two. The department is horribly understaffed. They feel the only way they can keep up is by making sure there is little different from point to point.
I firmly believe in having a COE on every machine. But I also believe that a user can and should have the right to software they feel would enhance their work experience. As an IT guy would you really know if MATHCRUN2002 helps that user or not? Make sure all users run the idea by you first and let them install it. As long as they have the understanding that is isn't supported and if something on your machine can't be fixed quickly you will return the machine to the COE.
BTW the two reasons I listed at the top are a result of poor management. Usually you end up with fascist IT directors when they have no concept of how to really run a computing environment.
--- I do not moderate.
The moral of the story is simple: programmers want to be free.
-CT
SOE = Standard Operating Environment
;)
Just so ya know... I had to look it up
antidigerati
(guessing)
Standard Operating Environment or
Standard Office Environment
I have worked on a system that was air-gapped for security reasons. You had to jump through hoops to bring in any software, and the process was so painful that it was rarely done.
We survived, but we didn't have as many neat tools as would be nice. We were just kind of used to it and homebrewed simple things or made do with what we had.
On the other hand, going to that sort of system from a more open system would probably damage morale, a problem not encountered by a system that's been closed since its inception.
Jack Valenti and the MPAA are to technology as the Boston strangler is to the woman home alone
Consider something simple -- automated testing. If you want automated testing to work, you need registry settings to prevent your programs from popping up dialog boxes if they take a long walk off a short pointer or some such. But those same registry settings would be completely inappropriate for real development, when you want the opportunity to pull up the debugger. There is not a single One True and Holy Registry -- you always need to tweak reg settings.
--G
Unfortunately, vmware has gotten rather expensive, and plex86 probably isn't ready yet (please, if you can help the author of plex86 find a good job, preferably working on plex86, do so). But if you are willing to pay for Win2k and Win2k software, the cost of vmware is small in comparison.
Otherwise, you may be able to work on your own laptop...
Oh, if you are doing real-world Microsoft Windows development in Visual C++, a "locked down" environment is probably too constraining. If you are just developing algorithms in C++, or if you develop in Java, it's probably doable. But forcing people to use a specific set of tools is not exactly the way to keep developers happy.
Developers should not be treated as sheep. Even writing mundane input routines is a creative process, and requires a decent amount of both technical know-how and intelligence.
Would a company consider telling all their advertising and marketing people that they can sit at their drawing boards but not adjust the height, angle and lighting of their workspace? If you treat developers like idiots who can't manage their own workstations (i mean geez!), that will show through in the quality of their work and their morale.
---
Play Six Pack Man. I
SOEs are fine for USERS, not for developers. Silly PHB. Such an endeavor is doomed to fail. I work at a place where an SOE in force. Development groups usually get special exception to obtain admin rights or else they couldn't even get off the ground.
The real problem is that management never thinks of implementing multiple tiers : More restrictions on Office worker types, less for development -- AND NONE FOR LABS! If you're on the group who's testing, say, WinXP(Chi-Rho) for deployment, you can't be fighting 'access denied' all day.
We wouldn't lock down our development staff. It would just be too big of a burden on us and them. My support guys would constantly be running back and forth.
BUT, I can see why they'd want to do it. By far our worst offenders for installing unlicensed and non-standard software (not dev tools) are developers. And frankly, 3 out of 4 developers I meet (DEFINATELY not normal Slashdot developers) can't fix their own PC when they break it. I'm amazed at the lack of understanding on the base system...I don't mean really get in there, but just simple things a real "power user" would know.
Make people receiving new accounts sign an agreement that they will not upgrade their installations with unapproved software.
Fire those who fail to comply.
Then you'll still be able to do your job without having to go around unlocking registries.
--Blair
"Are B-schools spending all their time on cultural diversity and takeover avoidance?"
I worked in a place that moved from Windows 3.11 to Windows NT (but they still thought 32-bit programs were 'a passing fad'). They locked down the registry so tight you couldn't connect to a network printer. I had local admin rights for myself and my development team, but they decided that that was 'insecure'and were going to change it, but I left before they implemented that stupid policy.
www.lucernesys.comHorizon: Calendar-based personal finance
It sounds awfully like your sysadmin is a lazy bum and can't be bother with support so (s)he's imposing these stupid rules to make his/her life easier. Resist, boycott, protest but don't let this happen. Any permissions, restrictions and access control are usually a huge pain in the ass. I'm in the opposite situation to yours. We use windows for development and Unix for staging/deployment. All unix work must be consulted with the Almighty Unix Sysadmin. The result? Nobody wants to deal with the asshole so noone bothers testing things on unix anymore and our app sucks in the production environment, all thanks to access braindead restrictions our sysadmin keeps coming up with. I think my company is fucked as a result and so is yours by the sound of it. Dust off that resume right away is the only piece of advice I can give you
Your pizza just the way you ought to have it.
Doing any significant development, you're not likely to need a lot of time working on registry modifications procedures, with the exception of a save settings routine in the Setup window. Actually, if you code it right you shouldn't need to create keys in the registry at all if they aren't that important. It should allow the program to continue with default behavior if the key doesn't exist, or cannot be created. Give the user a warning on errors that setting modifications couldn't be saved because you couldn't modify the registry. Chance are that some customers (if this is commercial software) may have the same restrictions. And if you're storing anything more than settings in the registry, then you're most likely storing the data in the wrong place anyways.
The only thing I can think of, is if you are doing some program protection that stores some encrypted values in the registry. I think IT will understand if thats what you're developing. But after you're done developing that, then it should just be a black box and you don't need to test it again.
And most likely you can get the keys for your software's settings to be left open. It's not unreasonable.
It's horrible!
Where I currently work, no software can be installed, and much existing software breaks. Windows media player causes a GPF, and many enhanced websites cause the machine to hang. The registry is locked down, and I don't have rights to "program files".
Every time in the past I've needed a piece of software, it generally takes days to be installed, and the entire chain of command has to OK it. If we directly submit a request be it for software or support, it gets deleted.
This completely and utterly lowers productivity. If I need something and I need it now, it takes days or weeks to make it happen. Problems or requirements that could easily be taken care of by the user are not possible, resulting in delays and wasted time.
Plus, IT stops by once a week to add software, odbc connectors, or make other changes. Those are things I could very easily do myself. Doesn't IT have better things to do?
I'm surprised they let me add bookmarks. Don't even get me started on firewall rules.
Instead of a registry lockdown, why not have an automated licensing check run on the companies software. You would have a program that scanned registries across the network for installed software, and check the installation against company licenses. It would quickly ferret out things like pirated copies of Photoshop and the like.
No, Thursday's out. How about never - is never good for you?
90% of the developers won't be able to get anything done. The 10% that can hack around it will be the only ones able to code.
I've had a similar fight everywhere I've worked except my own company. I even had one IT director running around, asking everyone who I worked for, so he could complain about me running Windows 2000 when they weren't ready to migrate everyone yet. (Someone finally told him I worked for the CTO and he gave up.) These paper f-ing MCSE's get taught how to run a Windows network full of secretaries, phone droids, and marketing weasels. None of their classes or cram sessions talk about administering a network for developers. Maybe they should have a special cert for that.
Personally, I welcome the challenge of any paper MCSE that wants to try to lock down my machine. I use a laptop running a tightened Win2000, never leave it unlocked, and don't log onto the domain. They have to force my boss to make me let them change my box. Not gonna happen. Even worse, I tunnel my web browsing over SSH2 to my OpenBSD box at home. They'd really hate that if they noticed.
I manage a the IT structures of my small business clients: I urge then to decide on the balance between freedom/security on an individual employee basis: A competent office manager who knows what a potentially damaging email attachment looks like should have free reign, while the ditsy secretary who wants 'the AOL internet thingy' should have a locked down box.
Moneyed corporations, non-working 'poor' and criminal prisoners are turning productive citizens into tax-slaves.
It's a great idea that works well. It drastically lowers support and maintenence costs, and helps IT leverage their budget against something besides the help desk.
Now, for developers it presents a HUGE problem. However, the way around this is to make sure that the developer's machines include virtual machine software like VMWare and a set number of "development virtual machines" that the developers are free to do whatever they want with!
This does a number of very positive things. One, it keeps the developers from accidentally doing something that messes with company network, since the "development" machines are now all on their own virtual network inside a computer. It keeps IT in a state to be able to maintain the local network and systems and INCLUDE the developers. And it allows for everything to be standardized. Everyone goes home happy.
Now, where it won't work is if the developers won't be given a powerfull enough system to run multiple virtual machines, or the IT people refuse to entertain the idea of allowing a virtual machine product.
When either of those things happen, the results are either bad or worse.
The important thing is to raise these issues early in the process so that the business decission makers can be made to see the sense and reason behind giving the developers their own play environment in the form of a virtual machine.
...if Linux was banned, hell I'd probably start looking for a new job. I don't use windows for any serious work, the Windows head on my desk runs winamp, outlook, and a web browser, that's it. My productivity would be severely (negatively) impacted by being forced to use Windows, even more so by a locked down version.
I'm the big fish in the big pond bitch.
Developers should really, really work in a sandboxed enviorenment. I'm talking about a development network that is cut off from the rest of the internet. Development work is directly contrary to modern security philosophies. You have to make it work first for proof of concept, then figure out how to make it secure.
Luck favors the prepared, darling.
It should be fine, assuming that the environment includes everything the developer needs. Of course, if the standard environment includes everything the developers need, then you're going to be getting licenses for a lot of things for a lot of people who don't need them.
Of course, if the people are developers, they are presumably going to develop something that's not part of the environment. If they can install their project, they can probably install other stuff.
I work in System Integration/Engineering of digital cable systems (headend, transport, set top boxes, etc) and my job requires that I'm capable of supporting any piece of equipment throughout the entire system. Conversely, I am using windows 2000 here at work and do not have rights to install any software or even make setup changes to my machine (this even includes the system time.) As you might imagine, this makes things very difficult for me as I am constantly having to track down a spare laptop or a computer in the lab that isn't being used (and there aren't many of either) in order to install applications that deal with the individual components of the system. The main problem is upgrades to software, this stuff is all brand new, emerging technology and so it is updated at an insane rate, so for instance if I need to update a console emulator for the control console of one of the headend controllers, I have to send the update to the IT guys, file a ticket, and wait for him to have time to install it on my machine. Luckily I have the flexibility of a large lab to work in and I can find ways around not being able to use my desktop in my cube. However, if I was not restricted in such a way I would be much more productive, as the very nature of workarounds is to produce more work, and reduce the amount of work I can finish.
To sum up my opinion: developers should have "power user" rights. They should be able to do whatever they want to with their machines with the understanding that if they mess it up, IT will send it a fresh new image that will wipe the computer clean and start from scratch. They should not be given administrative rights because then they would potentially mess up the network. Having your developers work on desktops with restricted access is like having them work on dumb terminals and results in loss of efficiency.
~ now you know
Check this summary:
Companies is putting in a standard. Can't modify registry. What am I to do?
Being a consultant, I run into this all the time.
First question: What do you do that REQUIRES you to change the registry? Does your programming? If so, talk to your boss and get yourself cleared of the policy.
Second question: Is there someone higher in the company than you (higher in rank, not drugs)? If so, talk to them about how to handle the situation. If not, you got to go to System Support and talk to them directly.
Regardless of how you answered, you need to either talk with your boss or Sys Support, not slashdot (which may be why this SOE is being implemented in the first place).
This really isn't a question for ask/., its just a developer griping about his job. Personally, I think this shows a lack of trust (pirating software, slacking off, etc...) or the lack of developer computer competence (need a standard for easier fixes).
Either way, it doesn't sound like the company likes their employees, and I'd take off. But for contractors, you just grin and bear it.
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
One thing my company seems to have overlooked is the ability to create shorcuts via the wizard. If I right-click and choose New Shortcut (on NT4), the wizard aborts and I'm left with a "New Shortcut" on the desktop. I then have to manually edit all of its properties. How about small applications that only a few people use? I distribute a database frontend made in MS Access. At least one of my users was unable to overwrite the old version. Heck, I can't even add printers myself.
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
One thing to consider is how tolerable employees might be of working under such circumstances. Some people, especially those that actually know how a computer works, get pretty testy when free reign over computers is taken away. I have personally turned down jobs because I was told that I would have no control over my personal workstation, and know other people that have as well. Good, creative people do not work nearly as well in very restrictive environments, and creating such an environment makes it likely that you might lose some of them, and that others might not be willing to work for you to begin with.
The reason for the lockdown isn't to try and restrict people from screwing things up.
/.ing etc.
Although IT can be faced with lots of problems from people who screw up their systems by trying to use programs that aren't supported, there are other more political issues.
1) Productivity. I'm sure my company would love to stop people from VNCing, ICQing, MP3ing,
2) Legality. Your company doesn't want you using pirated software, or software that the company may have some licenses for, but not enough for everyone and there mom to have Photoshop installed.
The desktop environment my company uses doesn't lock the registry down or anything, but periodically polls a server to see if all the installed software that is recognized, is accounted for. It apparently has the ability to uninstall software that isn't recognized, but they have (thankfully) not turned this "feature" on.
the anonymous poster below you got it right - it's the people who think they know more than they do that cause problems and need to be locked out.
:)
Besides, shouldn't *development* be done on a consistent environment that's seperate from the buisiness-access mahcines? If people are writing code that needs to mess with teh registry, they should have a mahcine that can do that, but that machine should not really even be on the main network - it should be on a *development* network, and the developer's primary machine should be a locked-down corporate workstation, perhaps even a thin client or whatever. Either way, the corporate workstation should be locked down to protect the users from themselves, regardless of how much those users think that they should be the admin.
Everytime I saw such a move, IT would push to treat developers like any other office clerks. It never worked.
The problem is, IT is solving a real problem. It is impossible for any company to mantain a support force that can handle any and all configurations and prevent unauthorized software installations by people who don't know what they are doing (like in "Hey, my friend just send me this great Back Orifice game, let me install it").
But developers are beasts of a different kind. In the long run, the underpaid IT tech guy will lose. Always. All my NT machines, and I had some during the past years, were mine in every sense. Administrator passwords were cracked, domains were abandoned. New, local domains were created. Linux machines were installed to handle development projects. IT never had a chance, because we were always adding value, they were always a burden.
And we never did it out of despise for them. But because the work had to be done and when work has to be done you can't wait for that same underpaid IT guy to come around to upgrade Acrobat Reader or install Visual Studio beta X.
And for the reasons above, the development boss would always prevail over the IT boss when a complain was send up about those pesky developers that wouldn't stand in line. And I was, at different times, the pesky developer and the boss that had to tell the CEO that "No, we can't play by IT rules unless you want version n.m to be x months late". Can you guess the answer?
Just use one of the Linux distros that boots from CD. You can mount your Windows partition to read and write files, but otherwise, you're not touching their installation. I've worked with a few insane companies, but as long as you have a boss that will back you up, I think this should work fine.
;-)
Bottom line: they're worried about the BSA telling them that they are going to have to pay thousands (or millions) of dollars because of licensing problems. You're booting a CDROM that the distributor tells you to go ahead an make coppies of, if you like. Think about your boss explaining that to some IT manager with a huge grin on his (her?) face
Slashdot-editor comments aside, certainly NOT ALL 'real' development requires access to the registry, just as NOT ALL 'real' (say) Linux development requires root access or any number of other privileges commonly denied users. For instance, most developers don't have permission to run ifconfig; but how many of them really need it ? Restricting access to the registry makes perfect sense in exactly the same sense that not everyone needs to be in group wheel.
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.
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.)
We did this in the I.S. department. because the corperate dweebs felt that the local IS had no need to have any more rights.
Run a crack program NOW on your machine to get the administrator password. Then add your domain login on your machine into the local-machine's administrator group.
voila, thay can put whatever restriction they want on he domain logins, your administrator group rights override the domain rights.
Works great and lets you actually do your job instead of letting the morons in power screw with you for the reason of satisfying their power trips.
(Sorry, front line IS/IT need administrator rights to fix things quickly... How the hell is the help desk going to log me into that machine as administrator remotely when the T-1 line is down? or if it has network problems..)
Oh and their answer is usually "sent that machine to us and we'll fix it in a couple of weeks.." No thanks, my boss wants it fixed now.
Do not look at laser with remaining good eye.
There are a millions reasons developers can not work on a locked-down system .
1) Developers need to learn and try new tools and technologies. If not, they'll be obsolete and eventually worthless to the company.
2) Every project has different needs for technologies. The overall development management may offer coding standards, and chose some tools over others, but that will never cover everything.
3) The receptionist may be OK with letting the IT group have full control on his computer. Programmers, who often run circles around IT support staff will fight, whine, and gripe if subjected to a heavy handed IT department.
4) IT support staff does not have the skill to perform installation and configuration of necessary developer infrastructure. A short list:
-integrated development environments
-compilers, patches to compilers
-web servers, exotic features of same
-Databases, oracle, sybase, postgres,mysql, access
-middleware
-specialized hardware and drivers
5) Then you have the occasional oddball document in some format that can not be handled by whatever is preinstalled on your system. That problem can be solved in many ways, but a locked down environment will waste a lot of time:
-developer finds and installs a conversion utility of viewer, takes 15 minutes at most
-developer must ask IT support to install such tool. Support staff asks IT manager for permission, developer must argue his case. It manager says no.
-developer hands document off to tech writer or someone else with the peoper software.
6) Then there is trust. If you can't trust your developers to manage their workstation, you shouldn't trust them to write code either.
Testing
-------
The only place a locked down environment is a big help, is for testing. However, an IT support group is not the proper organisation to deal with that. Testing and code release must be responsible for the test configuration and environments. And the locking down here means locking down configurations and changes into source code control, so that the proper environment can be recreated. An MIS nazi with
a bunch of desktop monkeys would not be the right way to solve that problem. By using source code control, test environments would also be available to developers.
I've seen too often that some piece of software only could work on the developers machine and nowhere else, because of the combination of middleware, compilers, configuration and runtime environment was different from the statdard build environment and the official test environment. But locking down the systems does nothing to help with that. Rather the opposite.
Usually a good litmus test for any policy is to ask: "What problem are you trying to solve?"
If the it group comes up with a non-problem, or they can not address the consequential problems, you're in trouble.
-- Another senseless waste of fine bytes.
...is that IT has the One True Canonical Disk Image. IT performs backups of the network drives; if you want anything safe, you keep it on the network drives. Anything goes wrong on your machine, their first step is *WHOMP* reimage the machine.
Also IIRC they allow users to install stuff, make local changes and tweaks, etc. I think they might even have machine-local administrator rights. But if you change anything, it breaks, and you complain, *WHOMP*.
(On an ironical note, I work for a military research lab, and IT is not at all alarmed when users have local admin rights to their Lose2K boxes. It makes things far easier for everybody, including IT. (IT can still do remote admin.))
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Our solution has been to place our development environments withing VMWare sessions. We can move them around, alter them to our hearts content, and not screw up the host OS.
The only software we place on the host are licensed productivity type apps and VMWare. Now, granted, we license all our software appropriately, but not having to worry about reconfiguration of a machine sure is nice.
The "Undoable" partitions are nice when you are mucking around with the registry (or other OS level stuff) as if you screw up, you don't commit the changes. Works great.
We zip up the sessions and archive then backup them up. Restoring an environment takes about 1/2 hour...the time needed to transfer and unzip the VMWare session from server to workstation.
We can change available resources and OS's in a snap.
IMHO, VMWare is one of the best tools out there.
So yeah, one can develop in a locked down environment.
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 almost didn't post because there are so many answers already, but I noticed that no-one brought up the most important point: Without registry access you cannot do 'Micrsoft Component Development' with ActiveX, OLE and .NET!
Creating components using these technologies requires registry access because you have to register the components. If you cannot register them you cannot even run a simple OLE server from the Visual Basic IDE. Forget compiling. Forget C#. Forget C++ for most things. Ain't gonna happen.
So exactly what languages/component sets are you expected to use? Raw ASP? What do you do if a third party component fails to work as expected (as they *always* do) and you have to upgrade? This policy is so braindead I guarantee it will go away, at least for developers, sometime soon. In the meantime I would get my resume out were I you...
Jack
- -
Are you an SF Fan? Are you a Tru-Fan?
Financial Institutions (in my experience) have been implementing 'lock-downs' like this for years for security reasons.
When developers need to install/upgrade/whatever something they need to clear it with his or her suprivisor. This is usually as simple as: "Hey Bob, I need to install Blah v5.1" And Bob says "Sure thing".
Perhaps this could bring about inefficiencies if it is inconvienient to speak with your department head, or gain permission. But if this is the case you are probably already working in a horribly inefficient environment, so what is a few more hours?
The man who cuts the checks makes the rules. Funny how subjects like this do not come up when applying for a job. It is in the employers best interest to make your workplace efficient, if a new solution does not work they will change it.
And it's in every employee's to push back to policies that are stupid (such as a SOE for developers. Such a notion is absolutely absurd). Loyalty is doing your part to trying to stop ridiculous endeavers in the first place, and your posting (portraying yourself as a model employee that views management as blameless) is the model of the type of an employee that leads companies to failure: The prototypical yes man that'll sit back and be ready with a "I knew it wouldn't work!" after the fact.
I can smell a troll from miles away. Good try luser.
-- Another senseless waste of fine bytes.
I was being called non-stop as people had managed to screw up their systems by opening random attachments, installing tons of crapware like AIM, RealPlayer, and doing various other brain-dead things.
Shouldn't YOU be scanning attachments for known viruses on the way in to your network? Why is AIM and RealPlayer "crapware"? Because it might lead to (gasp) fun at work?
Of course, since they had no idea how to properly set it up to behave on the network, they caused the whole NT domain to get utterly screwed up.
Unless they installed it with a bad NIC, broadcasting bad packets, Linux can't "scew up" a whole domain. Correct me if I'm wrong, Linux people. The only way a domain can get hosed is if the PDC gets taken down. How did little ol' Linux do that?
I'm sorry to say it, but if you want to get any work out of a business network, you need to protect users from themselves, no matter how savvy they think they are.
As a person working at the director level, you claim to know more about computers than your technical employees? You are management, friend. It was people like your employees that wrote Windows, and the tools you use to lock down their dev environments. What you need to do is call a meeting, set down some action items, and request some deliverables or something that managers do. I had a manager like you once. He thought that setting up a web server took Exchange down. This was in 1995, and he doesn't work there anymore. Learn from his mistake, and let your people free.
If you fall off a building, go real limp, because maybe you'll look like a dummy and people will be like hey, free dummy
There's a great solution to problems like this: outsource your IT support to a company that knows what they are doing. As other posters have mentioned, IT is probably not the core of your business, it exists to enhance whatever your real business is. Because of that, it's a prime candidate for outsourcing. Other companies can probably do it better than your homegrown IT dept.
I'm making some assumptions here:
1. You're in a relatively small company ( 500 employees). Large companies probably need full in-house support.
2. You're not an in-house IT person. This question was from a developer, and we're already operating under the assumption that there are draconian IT policies in place that need to change.
A good model is having a small support staff on-site, supplemented by the services of an IT consulting firm. Of course you don't want to call the firm every time someone forgot their password, but likewise you don't want in-house IT setting up your new active directory.
The advantage of outsourcing is simple: your company wants to pay as little as possible, so your in-house contact will educate users about not polluting their PC with Webshots instead of implementing some total lockdown policy. Hopefully your consultant will understand the balance between controlling a system and user freedom. But because your company wants to pay as little as possible for support, they will actively work to prevent problems from happening.
The obvious response is to try to talk them out of this misguided path. Failing that, there's something more to do than putting out your resume (I'd still put out my resume, working for bad management sucks, but there's fewer instant jobs out there lately).
If the policy requires your development machine be locked down, let it be locked down. Everytime your job requires you to do something you're not allowed to do (change a registry key, install the new compile of your program, etc), follow whatever procedure they have in place to modify your machine.
Document the time you spend filling out the paperwork, sending it to the systems administratiors, talking on the phone regarding the request, waiting for a response from systems administration, getting them back when they didn't install your program properly, and so on. Then, when they complain that your project is behind schedule, you can show them that 80% of your time is spent complying with their policy rather than doing the work you were hired for. That will go a long way towards getting control of your machine back.
----
Open mind, insert foot.
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
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
Ok, I give. What the hell is an SOE? And shouldn't stories expand the acronyms they use at least once?
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
I have a friend who's the head of development for an extremely large corporation. The IT department went around and locked down everyone's computers, just like you mentioned, but he was able to convince them that a locked down machine was of little use to a developer, and they eventually agreed.
--It's Pimptastic!--
This is a much more extreme situation to my last place of work. There, they objected to us re-installing the OS. At the end of the day, the engineering department got excluded from the SOE.
Most software engineers can trouble shoot software problems much better than an IT department, or if they can't, a co-worker can. We only ever expected hardware support from the IT dept. If I needed to reinstall the OS, they would take the machine away for 4 days, and then I would have reinstall all my apps once I got it back... or, I could reinstall everything and get back to work in one afternoon. Both departments benefit in the latter situation - all they have to do is re-add the machine to NT domain.
Generally, software developers need to be much more flexible. They need to try out new technology earlier on. Their software needs to be tested on these platforms before they become standard. There's a continuous need to install and uninstall software. A registry lock-down is stupid: how can you develop a piece of software that uses the registry (a very standard thing to do with Win32)?
When every developers starts calling support 4 times a day just to change a setting, they'll get a clue.
The Kruger Dunning explains most post on
how do you propose to install VMware in a locked down environment
I dunno, make it part of the standard dev software?
Reboot macht Frei.
Yeah, if you're doing ATL, for example.
EVERY SINGLE BUILD of an ATL project re-registers the component.
Fascism starts when the efficiency of the government becomes more important than the rights of the people.
Simple solution - development boxes go into their own OU, and thus programmers have full admin rights to the development servers, and their own workstations but nothing else.
However no-one gets rights to uninstall anti-virus software.
If you really want to be strict, and, as the topic seems to insinuate, that you're writing registry entries, well frankly, the software that you're writing should be using a particular registry tree, which developers can be given access to, usually HKEY_LOCAL_MACHINE\Software\your company name and HKEY_CLASSES_ROOT if you're writing COM objects.
If you're writting Windows drivers, well then, you need full rights.
The developers whined when it was implemented until asked to prove how it stopped them working/developing. It didn't. They shut up. They tried the same argument on the SQL DBA saying they all needed SA access, when all SQL requests should go trhough the DBA on their teams.
Frankly, once you have a standardised development build, exactly what software do you need to install and uninstall every day?
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
I'd say we ended up winning our battle. The first pass was that no one would be local admin, no one could install software, and no one could twiddle the registry. It turns out they couldn't figure out how to give someone local admin on their own system, and not every other boxen in the company. Apparently, after nearly relentless pressure from the development side, they only have two things they're going to ask of us: Run login scripts (to get anti-virus updates), and if you run a personal firewall, let through a few specific hosts/ports for reporting purposes. All in all, it looks like it's pretty agreeable.
They did tell us that while we have the right to run our own boxes, we also have the responsibility of running our own boxes. If you don't keep your patches up, or you abuse the privileges, they will come after you, and come after you mightily.
The truth about Scientology, Xenu, and you: Operation Clambake
Man, I love illinformed folks.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
Crimeny! Talk about yer heavy-handed edicts...
Someone's finally found a way to purge that last remnant of creativity and flexibility from the job of developing software. What a wonderful place that's going to be to work in.
Is there going to be a ``Directorate of New Product Ideas'' to tell you what new software you'll be allowed to dream up during the development process?
Don't suppose the originator of this story would want to leak the company name. I can think of a lot of people who would rather not waste their time even applying for a job with such a company.
CUR ALLOC 20195.....5804M
If you can get the powers that be to install one piece of software on your PC, ask for VmWare. Once that is in, you can install your own Linux (or even Windows -yuck!) environment, and be the king of the hill anyway. Most likely they won't even know what they are giving you...
In Murphy We Turst
The correct solution is for your IT department to invest a little time in training problem users well enough for them to stop being problems. Until you've done this, the user isn't the one causing the problem.
Once you've trained users, if any individuals persist in causing problems - stubbornly doing things you've taught them not to do - then that's an issue for management to tackle.
Lies completely and totally with what you are developing and what tools you need to do it. Period.
Everyone who's talking about 'no, you can't develop if you can't use the registry'. Hogwash.
Nobody can answer this question except your own developers. Not unless we have details.
The policy was pretty much as described. You didn't stick anything on the corporate network that wasnt approved (and ironically there was approved stuff I wouldnt put on my home lan!) and the developer lan was seperated by an airgap and a single firewalling file transfer box.
IS folks made sure we had 3COM mail (or rather they spent their life apologising for lotus notes), and fixed those boxes, anything on the developer boxes was developer problem.
Within Red Hat nobody expects IS to handle a box that the developers have done crazy things to. And we have a few core boxes the developers choose to manage instead of IS.
It is possible to find a good policy, but with the current Microsoft campaign of license auditing I can understand a lot of people running very very scared in the direction of total mind control.
See... in order to properly run a network, and keep things going, you have to have a good amount of control over the machines. I've run some fairly large NT/2000 networks... it's a real pain in the ass when someone, say, removes their computer from the domain for some reason, and doesn't know the admin password, etc...
On the other hand, I 100% agree that people need to be able to use the computer as a tool; it's there for THEM to do what they need to with it; not for me to tell them what to do. (developers, I mean).
So what I really want is a system whereby I can maintain the integrity of all the machines I'm responsible for, yet permit people to do what they need to with the machine.
And from what I've seen, unix is most DEFINATLEY the answer. Developers don't need root on their unix workstation.. yet they are still free to install anything they want within their own account. If it's really useful, it's easy for me to install it out to everyone.
It depends on what you want to develop. If you want to develop software, you're going to have a lot of trouble. Most projects already suffer from a lot of overhead that keeps developers from being fully productive. Forcing them to go through a bunch of red tape whenever they need to change something on their computers could worsen this exponentially.
On the other hand, if you want to develop migraines, ulcers, and a high turnover rate, sounds like you're on the right track.
What happens around here is that the SOE consists of crippled P200 boxen with all storage over the LAN. Locked down to a fare-thee-well, of course, and Linux forbidden on pain of termination. No personal machines allowed to connect to the Company net (including personal boxen from home) and in "the present business conditions" no new Company boxen or notebooks.
So, of course, we all just use personal machines for our work (including personal notebook machines) and test to our little hearts' content at home or on our own personal notebooks.
Everybody wins: the workers get their work done without being hassled by IT and the Company saves a wad on all the machinery, licenses, etc. that it doesn't have to buy.
Backups are sometimes a hassle, and we haven't gotten the ad-hoc 802.11b network to do CVS reliably, but otherwise things are pretty decent.
Lacking <sarcasm> tags,
No, you're missing my point. Actually I agree with you that programmers shouldn't whine about their job; if they don't like the job, go find something else. If they can't then they'd best shut up and put up. But my point is that, from the POV of an IT manager, making the programmers under you suffer like this is bad management. Your programmers won't perform well, and they will just be bitter and hard to manage. I'm not saying that programmers are right to be bitter; but if you're a manager and you cause them to be bitter by imposing unnecessary red tape on them, then don't be surprised they write a lousy product for you. And from a management point of view, this is a stupid route to take. That's all I'm trying to say.
Poll Mastah
Where I work (a software house), everyone is an administrator on their own PC (most running NT4/2000), and we regard this as essential. Just take a look at the number of "custom" applications that are essential to us, yet about which our IT support guys (who are actually pretty good) don't have any knowledge...
Of course, our servers are all run by sys admins under controlled conditions. But individual developers' machines, and machines shared by developers on particular projects, really need to be under the control of that developer or project.
Ultimately, sys admins can support the developers -- by installing standard apps like Windoze, Office and Visual Studio, by configuring the network connections and so on -- but they should never be trying to control the developers, who are almost invariably more qualified on their particular project than any sys admin can be.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
you do one of he following:
....
....
1. The "locked down" machine is used only for e-mail, memo writing, and other such administriva. Real development is done only on a separate "development" machine, for which the IT department takes no responsibility.
Let's face it. If you're doing something wonky, you don't want to wipe out your main machine. Reloading a development machine from local backups is something that most of us get real good at
If you're developing embedded code, you'll have to do this anyway.
2. Your definition of "development" is limited. You write the code, maybe write little unit test programs, and then pass it off to the "integration and test" department. They get to build install programs and such.
It'll work, if you have a very rigidly defined design and everybody sticks religiously to the defined APIs. This is the "software factory" approach. Fine, if you're working on a well- understood, well- specified problem, and everybody is working well within their area of expertise.
Note that at best, this just moves the lockdown problem to another group.
3. You're not developing "real programs". If you're doing, say, Perl scripts, then you might get around the restrictions by claiming that they're "only data".
Anyway, Bad Idea in general. I'll bet we all have our favorite "ditzy little utilities" that we carry around with us. IT can be very rude about such things
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
Mr. AC - I've been on the other side of the fence, and beyond. I do that for a living. I support EXTERNAL customers - who generally install whatever the hell they want on their machines, and I'm expected to support and fix it - even if it's explicitly stated that I don't have to support interaction with Application X - there's ALWAYS an exception. Usually a large, loud customer with deep pockets and a big mouth, and the ear of someone highly placed within my company.
I seem to manage.
Who is blamed when things don't work? We don't point fingers and blame. We analyze the problem, and find the cause. If it's not our problem, (as is often the case) we can sometimes code a workaround in our product. This is acutally very common, as many bugs in a given vendor's product are actually a result of something broken in the OS - that you end up having to code around.
When there's a known problem or conflict that can't be worked around, we document it and move on. Customers can look up the known issues on the web, and are informed not to run that specific configuration.
Do you see the difference here? We tell customers what specific configurations we know won't work. IT people tend to tell their "customers" only to run ONE specific configuration that IS known to work (in their lab - or most of the time).
The whole point of having a computer is so that you have a multi-function tool that can run in a variety of configurations to deal with a variety of tasks. When you start limiting that, you limit the usefulness of the tool - and the productivity of your workers.
One other point - which is really an observation. In my 10 years of doing this - the WORST customers to work for are ones that have strict lockdown policies on their network. It takes forever to gain access to the servers that cause problems, it takes forever to get troubleshooting data from these people, and more often than not, they tend to flat out refuse to install any patch or update until it's gone through months of their own internal testing. Then they bitch and moan when it takes our Tech Support too long to fix their problem.
I've had calls from customers who are expected to resolve problems with our products that don't have administrator access to the boxes they're supposed to be working on. How the hell are you supposed to try configuration changes? If an updated 3rd party driver is required, how the hell are you supposed to install that? These people don't think about how these lockdown precautions negatively impact workflow and productivity. Isn't productivity the whole goddamn reason for the supposed computer revolution in the first place?
I can see wanting to exert a little top-down control when 90% of your corporate network's bandwidth is being consumed by desktop MP3 servers. But a lot of this other stuff is just complete bullshit.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
their primary jobs are email, writing text/presentations/spreadsheets, doing forms on the web, getting information off the web, and other communications jobs.
The Registry is a terribly annoying system built to obfuscate application and configuration information and make it hard to move between machines. And tools that hide drivers in among the operating system guts have similar problems. If you wanted a clean environment, you wouldn't be using Windows.
There are lots of sales people, and individualized attention doesn't scale well.
Personnel turnover is relatively high, as great sales people get stolen by the competition or customers, the competition's great sales people get stolen by us, bad or unlucky sales people don't make quota and get booted, and in general they want to minimize training costs for computer platform tools, focusing the training on directly-business-related tools.
The standard computing environment is Microsoft, which means that Bad Things happen to it fairly often, and the most effective repair methods are destructive - save the user's files and wipe the computing environment.
A surprising number of tools can be developed as Excel and Word macros or other things that don't look like installing new programs.
All of this looks entirely unlike developers.
The really tough part for most sales people is supporting individual productivity tools that haven't yet received corporate support - everybody figured out Palm Pilot support really fast, Visio was a bit slower, and Dragon Dictate and some of the contact managers aren't widely used.
Does this suck for me? Yes, because I'm not just a user - I install all kinds of cool stuff off the net, partly because of the productivity win of having my personal email and environment on the machine I carry on the road with me instead of one system at home and one laptop for work, and I can read my personal email on the train.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
This disk image creates a floppy that boots a customized Linux kernel that allows the administrator password to be reset. And thats the chance of getting caught, that next time they come around to administer the machine they can't get in. But who's to say that they didn't screw up the password?
You can also look at tools such as L0phtcrack that try to brute force the password, done correctly that wouldn't raise eyebrows, at least until they decide to re-image the box.
But really, what kind of job is it that you have to go to these lengths to circumvent policy?
Bleh!
For those unfamiliar with the term, it is essentially a team, hopefully some distance away from the "corporate culture"
Yes, it can be a bit of a death-march at first. But if successful in reaching the goal, under budget, the manager can usually keep the team at the skunkworks
In the cases I've been blessed with, we get very little IT support, but we're all geeks anyway. Many of our development machines are definately not SOE
Our IT department begrudgingly goes along. On one hand, they hate it because of our self-sufficiency threatens their job security. On the other hand
further reading:
Productivity: A Personal Choice
Chief Programmer Teams
Intermittent Aberrations: Can Mature Companies Innovate?
How to Defend an Unpopular Schedule
healyourchurchwebsite.com - WWJB?
In a system on the scale of which you speak, with the problems you describe, you should have a dedicated test network (logistically) between your development network and your production network. The test network should be identical to your production network. Changes moving to production come only from the test network (where they have been for a pre-determined amount of time/usage) and are approved on an item-by-item basis before they are moved. Development changes move to the test network after being approved on an item-by-item basis, at which time a non-coder sets the schedule and criteria for a successful migration to the production network. Failures at least reset the clock.
You can document your processes all you want, but if you don't know how to run a large-scale production environment you'll need titanium boots to keep from shooting your feet off. Sensible production controls address every issue you're talking about and have no bearing on the question of whether IT and development get to fight over desktop admin rights.
Btw, if your IT people are good, your managers are good, and your developers are good they help each other and don't have turf battles. I'd hate to try to find the weak links in the story poster's company. What a fucking nightmare that place must be to work at.
Of course, if you've picked NT systems for a production site then you've got more serious endemic problems than underdeveloped production control.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
I work in a small dot.bomb, that has managed to survive over the last two years. I have one other support person, who shares in supporting about 20 servers, and 40 desktops. Our number one responsibility is to make sure that everyone in the company can do their job, not impose draconian , BOFH policies.
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?
Or, they could not do that. Developers could do many things that they do not do.
Developers having admin rights to machines means that they can build and install their development tools anyway they want, and they can patch/not patch as they see fit.
It also means they can fix problems without waiting weeks for them to otherwise be fixed (yes, I have been the recipient of that while working for one of the top defense contractors).
Have you ever witnessed the example of developers using beta or pre-release versions of libraries, compilors, or OSes? And then wondering why problems crept up when they moved their applications to production. Witness the recent problems at MS where code had been built against beta libraries - which left debuging turned on for applications that were then moved into production ... not a good thing at all.
Yes, that is a problem, but your solution is just as large a problem. You can solve such issues with guidelines and good management skills; the draconian route can work, but it's not the best route in my experience. I've fought with it. I've seen teams fall down for it. I've seen projects die in a flaming mess because if it. The 'it' I'm refering to is beaurocracy, and what you are advocating is a particularly severe form of it. There are other, better solutions.
Besides, most of the people I've know that advocate your position usually had some sort of power struggle involved (my last one was Thou Shalt Not Use PowrerBuilder because Visual Basic is Blessed).
The wheel is turning, but the hamster is dead.
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.
"I'll just chip in a bit for RedHat: I actually have that installed on my university machine." - Linus, '95
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.
There's another argument against requiring locked down systems for
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.
You're going to have to look at the situation and answer this question (honestly): why was it that the developer felt s/he had to do this on the sly?
My experience is that there are generally two cases, not mutually exclusive.
The other thing, of course, is to see if the unscheduled change makes the app better.
If your environment is as locked down as I suspect it may be, what you're describing here could just be a visible instance of what's widespread practice: people adding free software elements to their work environment because it makes it easier to get the job done. Complete freedom is clearly inappropriate, but a large tolerance for diversity is a strength.
And note before you disallow all such projects that UNIX itself began as an unauthorized project by Brian and Dennis on some old hardware.... Punishing inventiveness does lead to one predictable result. I'll let you do the math.
What part of "gestalt" don't you understand?
Boy, you guys are NICE re-imaging their drives! Here at work if WE screw up one of our drives (yes, I'm a developer), they come in with a boot CD, install Windows ONLY, and WE are expected to set the rest up ourselves!
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
Boy, you guys are NICE re-imaging their drives!Here at work if WE screw up one of our drives (yes, I'm a developer), they come in with a boot CD, install Windows ONLY, and WE are expected to set the rest up ourselves!
Seems strange. It's quicker (by far) to use ghost or something similar. And if you use imaging you end up with a fully functional (business) system. For instance on the old compaq I use as a desktop it takes the morning to reinstall Windows 2000 and Office 2000. It would probably take at least another 1/2 day to get all the standard and custom apps set up. I can ghost to the same setup in 40 mins.
Much as we'd like to (and it is something that we have considered) we haven't found a quick developers solution because just about every developers' machine is unique in most tools (and no, we're not stupid enough to say "This is the company editor, you will use this even if it makes you less productive"). The best we can do is make sure that when a machine is hosed they can get up to a known standard condition quickly containing everything they need as an employee, and that they have easy access (via CD or network share) to any tools that they then have to re-install.
In your situation if there is a single tool, application, or setting that has to be installed or set before your machine is functional, then your IT support department should get their arses kicked: they are costing themselves and every employee time and money, and that is not acceptable. There would be a management decision to be taken if IT support are saving money at the cost of some developer's time, but dollars to doughnuts that isn't the case here. It looks like a "you've screwed up, therefore you have to be punished" mindset, which sucks.
SOE = Standard Operating Environment
In that case the matter is resolved easily. Developers by definition do non-standard work. That can't be done in a SOE. Developers HAVE to be able to play and experiment. They HAVE to be able to write applications that need to write to certain registery keys which are protected by the SOE (think of installers, experminenting with different configurations, etc).
This is your sig. There are thousands more, but this one is yours.
Your right that Ghost would be faster, but they CLAIM that there are so many models of PCs around the company that they can't do it. We do have everything from p90s to 2 gig machines around - Penny wise, pound foolish
-- 73 de KG2V For the Children - RKBA! "You are what you do when it counts" - the Masso
Unfortunately, however much you may wish it otherwise, this is not a subjective issue. A programmer who is comfortable with his or her working environment and well supported will perform better than one who is not. Whether or not the handicapped programmer wants to perform better is irrelevant. This is simply Management 101, and applies to other workers as well, of course.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
there are commercial artists. they don't love creating mcdonald's billboards. they might go home and paint frescos to satiate their creative urges. but they do their damn work because they are paid to, and programmer shouldn't be held to different standards.
Sure, but in most workplaces, they get the tools they want. That's how you can tell you're in the graphics departments. Typically, their desks are the only ones in the whole company that have Macs rather than PCs. There's a difference between working on a 'less interesting but commercially valuable project', and having to do the same with lousy tools as well.
Programming IS a creative process. Any reasonable step to improve the creative flow of the programmers (wrt work projects) should be taken for the sake of the bottom line if for no other reason.
2 - "Proof in the pudding"
3 - Not everyone on /. grew up installing RedHat on web servers; I didn't.
4 - Fuck you very much for waving your worthless Sun cert and touting your "hardcore financial applications". I've written them and supported them alongside people whose names you know if you have any knowledge of Unix history. Let that sink in, you parochial fuck.
5 - It's not possible or desirable to sync dev with test with production in the face of a non-trivial version push (whether that's due to internal or external software). You're naive if you think there's any point in having three identical systems for these purposes.
6 - When I was doing production support on a large in-house 24-hour trading center, running applications my team designed and developed, we never needed to rush code from development into production. in spite of the fact that we were indeed dealing with systems that handled tens of millions of dollars in transactions an hour. Oddly, in eight years we never got to use our hot off-site backup trading center to do active trading. You did have one of those, didn't you? You know, "best practices" and all.
7 - Nobody called your workplace a nightmare (reread my post), although considering that an annoying fuck like you works there I might consider calling it one.
8 - Our company evaluated NT systems numerous times over the course of 4 years for various different applications and never allowed any installations other than the Reuters Dealer systems which Reuters was forced to support. Why? Because NT was never deemed robust enough to exist in our production environment.
9 - Fuck Marimba and fuck you too.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
Sounds like the most insanely expensive method to do the equivalent of a network boot I ever heard.
Is there a reason they couldn't just go with diskless machines?
-- Another senseless waste of fine bytes.