Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

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

Posted by Cliff from the coding-under-lock-and-key dept.
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?
This discussion has been archived. No new comments can be posted.

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

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

Comments Filter:

  • Registry lockdown? (Score:3, Insightful)

    by syates21 ( 78378 ) on Friday October 26, 2001 @02:54PM (#2484815)
    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.

    • Re:Registry lockdown? (Score:5, Informative)

      by Chuck Milam ( 1998 ) on Friday October 26, 2001 @02:58PM (#2484839) Homepage
      I don't even think a lot of *existing* application would run...

      Yes, I've seen this before. In a university environment I used to work in, we tried to lock down the registry...we had to make so many exceptions for various application that required full registry access to run (scary), that by the end of the semester we gave up on locking down and went back to rebuilding the systems nightly (which introduced a whole group of other messes...)
      • Yes, I've seen this before. In a university environment I used to work in, we tried to lock down the registry...we had to make so many exceptions for various application that required full registry access to run (scary), that by the end of the semester we gave up on locking down and went back to rebuilding the systems nightly (which introduced a whole group of other messes...)

        Just out of curiosity, what applications need full registry access?

        I'm not really a Windows developer, so I'm not familiar with programatically changing the registry. But I have manually changed the registry to allow automatic login [microsoft.com], and you may even be able to auto-login into the admin's account (BTW, the PCs I did this for were not on the network, and needed to boot straight to the desktop). Now, you need to know the desired password for the auto-login to work, but there may still be a security issue with a program that is allowed to read and write any keys in the registry.

        Does Windows allow full registry access by default, or does it make some restrictions?

      • That's because there's a hellava lot of broken applicaitons out there -- top of the list are MS Office 97 and Netscape 4.x. (Office 2000 and Mozilla are the cure.)

        On the otherhand, I can and do get most of my work done as an 2000 "Power User", which is a partially privledged group. Developers could maybe get an secondary admin login that they could use with Run As (su) to install software or whatever.

        Testing with the "User" level (which MS's idea of locked-down), caused lots of stuff to fail.

        Would anyone run a Unix desktop program that required root access? NO! But that's situation normal in the NT world, where 9x is tested first and not even Microsoft does full QA as an unprivledged user (see SP6). Shipping XP Home with defaults to give everyone admin rights is a huge lost opportunity to fix the problem. Eventually Microsoft is going to have to break the eggs to get the omelet made.
      • If the powers that be lock the registry to prevent writing to HKEY_CURRENT_USER, of course they're going to break a ton of apps. It's there for storing user settings.

        OTOH, locking down HKEY_LOCAL_MACHINE makes perfect sense and programmers who use it for user-settings should be shot. Twice.

        Developers need to write the administrative portions, so they really can't be locked down. Giving a programmer a C compiler and no registry access is like giving a soldier an Uzi, but no ammo except rubber bands. Well almost.

        • About a year ago, my programmers came to me with the suggestion that we begin using the registry for settings storage for our applications. The ONLY reason that was given, was that it was faster than parsing an INI file.

          Well, we still use INI or config files to store settings in. Also, custom built dlls, live in the apps directory, not out in win\system32. Pick up our apps, move them to a new drive, run them, they work. Saves on reinstallation expenses for our clients.

      • Re:Registry lockdown? (Score:2, Interesting)

        by headkick ( 24083 )
        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.
    • 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.

    • Re: What is SOE?? (Score:5, Informative)

      by antidigerati ( 195379 ) on Friday October 26, 2001 @03:05PM (#2484888)
      SOE = Standard Operating Environment

      Just so ya know... I had to look it up ;)

      antidigerati

    • A system with HKCU locked down would be unusable in my book. What they could do though is ensure that you aren't an Administrator or Power User on your own machine (stupid if you're a developer, IMHO) so that HKLM is read-only.

    • Re:Registry lockdown? (Score:5, Informative)

      by olsonde ( 156624 ) on Friday October 26, 2001 @04:57PM (#2485567)
      I'm assuming we are talking Windows NT/2000/XP?

      I'm also assuming by "Lock-Down" you are saying they have no rights to use Registry editing tools (regedit, regedt32, reg, regdmp, etc.) Also, no file permissions have been changed from their default.

      By default, only "Administrators" have the ability to add or change keys in "Classes_Root". All users have full control to their own user hive (ntuser.dat).

      For "Local_Machine, only "Administrators" have change ability to "Hardware";and "Administrators" and Power Users" have the ability to change keys within "Software".

      As a developer, all developed programs should be able to be used by a person with only local "User privileges", but the person installing the application will need to have administrative privileges, because they will need access to CLASSES_ROOT or LOCAL_MACHINE.

      So, if I was a developer writing an installation program, I would need to be able to test my installation code on a machine where I had local "Administrator" rights, but I would not need to have those rights on a machine I was compiling my source code on, since that only needs file permissions.

      Where I work, the developers are normal users on their development machines (Visual Studio, Team Fusion, etc.), but they test their applications on machines set aside specifically for their testing purposes (their development and test machine sit side-by-side, sharing a monitor, keyboard, and mouse through a KVM switch). The test machines get wiped out and re-imaged as much as a dozen times a day (with a bootable CD image), but their development machine is rarely touched by IT.

      In the rare instances where an app or development tool must run as local admin, we use the SU tool of the Windows NT/2000 resource kit. SU (we call it the Super User tool) will allow a specific application to run with elevated privileges.

      We also use a freeware tool called RegDACLS to change registry key security to allow evelated access to specific keys in the registry.

  • No, you can't. (Score:4, Insightful)

    by dmorin ( 25609 ) <dmorin@@@gmail...com> on Friday October 26, 2001 @02:56PM (#2484820) Homepage Journal
    Easy question : no. My group has our own Unix boxes and our own support group for most things except DNS changes and stuff like that and we still run into inefficiencies in getting routine things done on time. We do not have administration rights for our NT desktops in the sense that we can bring in our own OS upgrades, but we do have the freedom to install new applications. I can't see it working any other way.

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

    • 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.

    • Hell no, BUT!!! (Score:2, Informative)

      by Nijika ( 525558 )
      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.
      • You have to make it work first for proof of concept, then figure out how to make it secure.

        I disagree. It's far more easy to maintain security if something has been developed with security in mind from the beginning. Trying to retrofit security onto an application/system/protocol/network/whatever is a slow, painful, and usually impossible process, especially if the source code isn't available and the developers have retired/died/moved on.

    • Re:No, you can't. (Score:5, Insightful)

      by ladykadyj ( 230667 ) on Friday October 26, 2001 @03:24PM (#2485027) Homepage
      I would wholeheartedly agree with dmorin. I think it's perfectly valid to have a development department in charge of their own "space". I've worked in that environment very successfully and at the satisfaction of both the development and IT groups. They stayed out of our way and we actually helped them with some of their problems.

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

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

      Freedom is not for the ignorant.
    • The technical answer is "not effectively."

      You need admin rights to run a debugger that enters a secure part of the kernel. So, unless you're developing VB or Java or some other language that thinks disassemblers are dangerous, kiss productivity goodbye.

      The good news is it takes about 10 minutes to root an NT box, and from there you can just grant yourself admin privileges!

      John

    • I don't know how many times I've had this conversation with management. We officially have this kind of policy, but exceptions are inevitably made for developers (often after another meeting to determine exactly why developers need to do things like installing dll's and modifying the registry). There's just a real problem when a developer can compile a dll for an application, but can't actually debug it because the security policies won't allow it to be registered (which means windows won't load it at run time).
    • Ideally, in this environment, you'd want *TWO* machines. One with the "official" locked-down office automation environment, and one with your compilers and stuff.

      That's what we were going to do when my company was considering this ill-advised policy. Luckily, they rethought it.

  • Trust? (Score:3, Insightful)

    by Nick ( 109 ) on Friday October 26, 2001 @02:57PM (#2484824) Journal
    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?

    • Re:Trust? (Score:5, Funny)

      by scoove ( 71173 ) on Friday October 26, 2001 @03:25PM (#2485037)
      It is rather amusing, not trusting developers. By definition (apologies for being redundant), but developers do not work in a static environment.

      Having been in both ends of the pool, it never fails to amaze me at all the rules the corporate "golds" make up, then act surprised when development objectives get missed.

      I'd suggest a copy of Yourden's "Death March Projects" be left on the culprit gold's desk for their inspection. It won't work, but it'll be worth a few good stories.

      *scoove*

  • They can't (Score:5, Insightful)

    by well_jung ( 462688 ) on Friday October 26, 2001 @02:57PM (#2484827) Homepage
    We faced this issue when standardizing/locking desktops during our upgrade to Win2000. The only workaround that was agreeable to both sides (developers and IT) was to allow developers to have free reign, but not to expect anything more than "We can re-image the machine" from IT when said developer screws up his machine.

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

    • Re:They can't (Score:2, Informative)

      by nigelc ( 528573 )
      That's more or less what we do here. Each of our developers has admin rights on their own machine (not including OS upgrades), with the "you screw it up, you fix it" support agreement.
      Our source control system, critical apps, intellectual property, bug-tracking system and stuff like that are kept on servers to which the average developer has no admin rights. And only IT can add new machines to the domain/change domain properties for machines.
      It works quite well. There's a good mix of tools (shareware, freeware, commercial) and we can usually try things which might make our lives more useful.

      The only things IT mandate are that we keep the Virus Protection up to date, and lock the screen/log off when we go home at night.

      Propose this model to your IT folk -- it works, it's less trouble for most people, and you can weed out the troublesome alleged l33t developers who can't keep a system running without help!

    • Not all problems are the user's fault. The problem with this policy (We won't support you unless you let us treat you like a child who doesn't know how to use his computer) is that it cuts off any avenue of communicating IT's problems to IT. This is what has happened with the end-user phone support world. If your system differs from their approved setup in any way at all, then they won't even talk to you to find out if the problem has anything to do with the changes you made. They automatically assume it does and leave it at that. This is the reason so many cable ISP providers insist you have them install the modem for Windows and won't tell you the numbers so you can install it yourself for something other than Windows. If you don't cave in to the majority, then they won't listen to your support problems to see if they are on their end or not. You end up with monopoly by fear - use the monopoly product or we won't be accountable for any problems, be they our fault or not.
      • If your system differs from their approved setup in any way at all, then they won't even talk to you to find out if the problem has anything to do with the changes you made.

        Then you just demonstrate the problem from a "supported" user's machine. You can't blame them for not wanting to learn some foreign OS just to troubleshoot one problem (yours or theirs).

        • What if the problem isn't repeatable on someone else's machine, because it is specific to their setup for you? (NOT your local setup, but their setup on their end as it pertains to you.) To use the cable modem ISP example - what if they got your physical address wrong, so they enabled the wrong line for your account, so you can't get a connection? Or what if they spelled your username wrong when setting it up, so you can't log in? What if the problem is in a local router that doesn't get used when you travel to friend's house to try from there? These problems don't require them to know your OS, but they STILL won't talk to you unless you have the OS they want installed. They refuse to escalate the problem past the basic list of idiot questions, and that list insists that you be running the OS they tell you to.

          They wouldn't *have* to know your OS if they would just believe you when you tell then the source of the problem.

          • refuse to escalate the problem past the basic list of idiot questions, and that list insists that you be running the OS they tell you to

            So do what I do - Lie. As they'd ever know.


    • ...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.))

  • 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.

  • Yes, but at a much slower rate... (Score:4, Interesting)

    by Gid1 ( 23642 ) <tom@@@gidden...net> on Friday October 26, 2001 @02:59PM (#2484842)
    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 =)
    • Let me get this straight here: The guy is developing Windows applications, and specifically said that he is not permitted to install other OS's, and your suggestion is for him to run Linux. You rode the short bus to school, didn't you?
    • No internet access for a *nix machine to develop a website using technology that runs on a *nix platform??? What are they smoking??? Even with the current state of the economy I think that's one I'd be laughing my head off as I walked out the door. Of course I guess I'm one of the luckier tech people, I still have my job and they don't put stupid restrictions on us (at least not yet).
  • 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.

  • Development Lab (Score:3, Interesting)

    by ThomasMis ( 316423 ) on Friday October 26, 2001 @03:00PM (#2484847) Homepage
    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.

  • 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
  • In some cases I think the developer could work okay. Depends, on what apps the developer uses as some wont work if they cannot modify the registry. Think of it this way, a developer would not be able to change the setting in some of the programs if they cannot access the registry.

    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.

  • If they insist (Score:2, Insightful)

    by dgb2n ( 85206 )
    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.
  • 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 have worked in an environment like this [lucent.com] and one of two things inevitably happened on each workstation:

    • Employees spend large amounts of time circumventing the access controls. Some are caught and disciplined (though very infrequently). If the systems rely on Tivoli or some other sort of automatic updating, the "free" developers often need to copy software from their co-workers so that they have (for instance) the latest version of the development environment. After the restrictions are successfully removed, the programmer can usually go for several months before having to "defend" his machine from a recovery CD or otherwise tweak it to keep the controls out. Net result: productivity goes down.
    • Or, the user learns to work within the constraints of the system. They are on a first-name basis with the administrative support staff, whose intervention is needed to change the system time or screen saver delays. Very little time is spent developing software and a lot of time is spent on trivial matters. Systems support staff all get large raises, lots of overtime, and increased budgets because of their heavier workloads, and less actual work gets done. Net result: productivity goes down.

    The moral of the story is simple: programmers want to be free.

    -CT

  • Yes, but it's no picnic.

    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.

  • 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
  • If you make one of the applications "vmware", maybe it doesn't matter that much. This could still make the company happy because the basic machines will keep on running, E-mail and web browsing keeps on working, and the virtual machines don't do anything bad when it comes to networking. Also, resetting a virtual machine to a pristine state only requires removing a file.

    Unfortunately, vmware has gotten rather expensive, and plex86 [plex86.org] 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.
  • The goals of this SOE are to prevent users from installing unlicensed software, plus some support issues.

    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?"
    • This fails to address the real problem, which isn't the physical details of how to lock out the developers, but whether or not locking them out is a good idea in the first place.

      It is not. A developer that needs a quick little tool doesn't need it next week after a long bueracratic approval process. He needs it today. Now.

      Although putting the policy on the questionaire right away at the beginning during the interview process would be a good idea. It would allow the good developers to know that this is a company to avoid.

    • Fire those who fail to comply

      So, you fire the competent people who get caught, drive off the talent (who chafe at such behavior) and end up with the people sneaky enough to avoid your attention and those with no real creative drive. Sounds like fun.

  • 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
  • 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.
  • First of all, why would Linux be banned? Its not like you're going to be running anything illegal on it.


    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.

  • 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.

  • 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.
  • 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.
  • 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.
  • 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:)
  • 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.

    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, /.ing etc.

    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.
  • 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.

  • Not Enough Information (Score:5, Insightful)

    by pmc ( 40532 ) on Friday October 26, 2001 @03:51PM (#2485191) Homepage
    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.

  • I found the responses to the initial question particularly amusing today because over the past week it was discovered that a development group installed an unsupported free app on a dev/test system and then made their code dependent on it. Of course this was discovered after final QA testing so there were obviously some methodology issues at work too. My personal feeling for Open Source software aside (yes, it's all I use at home) this behavior just isn't conducive to a long, well paying career at a major US financial institution.

    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.

    • Run a crack program NOW on your machine to get the administrator password

      And if they find out (like noticing that you're a local admin), they fire you if you're lucky. If you're not lucky, you face criminal prosecution.

  • 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.

  • 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
  • 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?
  • 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.
  • For most types of application development, yes, you certainly can lock down the developers' boxes and still maintain productivity and effectiveness. This is done in regulated industries (pharmaceuticals, financial services, aviation, etc) all the time. In this sort of environment, stereotypical "I must express my creativity through code or I will die" programmers will not thrive. They will quit and you will be left with a more assembly-line, less creative team who deliver mediocre but functional applications consistently on-time and on-budget. If this is what you want, by all means lock down the boxes. Just make sure your recruiting practices select people who will fit this sort of culture; i.e. people who will be happy with a locked-down box.

    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

  • Hey, no problem... (Score:3, Interesting)

    by dasmegabyte ( 267018 ) <das@OHNOWHATSTHISdasmegabyte.org> on Friday October 26, 2001 @04:50PM (#2485529) Homepage Journal
    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...

  • SOE? (Score:2)

    by p3d0 ( 42270 )
    Ok, I give. What the hell is an SOE? And shouldn't stories expand the acronyms they use at least once?
  • 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.
  • 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 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.

    1. tiny apps. just like the recent post. [slashdot.org] 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. ;-) 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

    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. ;-)

  • Locking down makes for useless development (Score:3, Insightful)

    by hyrdra ( 260687 ) on Saturday October 27, 2001 @12:16AM (#2486542) Homepage Journal
    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.

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close