Developing in a hostile environment

Question

OK, not that kind of hostile. I'm curious to hear how people deal with developing on big corporate networks that mandate all kinds of developer-unfriendly services and policies on desktops (think ProQuota, over-zealous virus scanners, no local admin, no access to SO). I've previously used virtual LANs used effectively, or completely seperated parallel networks, but these aren't always practical. Any other tips?

Answer 1

Bringing your own laptop with the necessary tools is always a good way to overcome these man-made hurdles

Answer 2

The most important thing (if possible) is to recruit support from your boss.

Unless he's a PHB, he will often understand the impact of these restrictions on you, your team, and indirectly on his success. If the requests are reasonable, he can provide the buffer if you do go against IT. In addition, if the entire team or other developers seek the same policies, this "group bargaining power" can be used to create special policies.

Generally speaking, large corporations are over-zealous about legal issues and information security. However, IT departments generally hate dealing with numerous requests for support from the same person. Sometimes, if you show a clear harm to productivity from a project (e.g., you use a lot of temp files and the anti virus hits them), or that your program has to be installable from administrator mode, they will sometimes reach a compromise. You may have to sign something stating you would not use an administrative access on your machine to install illegal software, but you'd still get admin.

In the few cases I have gone for job interviews (I'm mostly in academia but worked some in the industry), one of my greatest concerns was the amount of control I had about my computing environment, from hardware, to software, to administrative rights. If I cannot be trusted as a developer to manage my own windows box, I don't feel I should be trusted with a mission-critical system.

Answer 3

I haven't tried this myself, but I once saw someone say that the central IT gave in and let him administer his own workstation, after he complied with the policies by submitting to them a change request form with a list of the first 300 things he wanted changing on his workstation.

Answer 4

Anything that interferes with you doing your job is good to bring up in a meetings.

Ex:

• This Virus Scanner runs 4 times a day while I am at work. During that run my compile times take 5 times as long, and the use of my other development tools is brought down to a crawl.
• The web filters are overzealous. I have attempted to access sites x, y, and z for extra development information, and have been unable. The time it took to find a good resources was doubled because of this.

And so on.

Answer 5

Bring you own laptop but DON'T connect it to the network (and make it obvious that you do not intend to).

Copy stuff e.g. Visio diagrams over via USB drive.

If they don't allow USB, you can access the internat from outside and email the files. Using OWA via browser sometimes gives you more rights to send files.

Answer 6

I would explain your issues to your boss and/or sys admin, if they are receptive and agree its a good idea to let you have control over your workstation(s) then problem solved, if not I would walk from the project/job before your probationary period is over.

I was in a similar situation once at a large goverment corporation and it turned out management not be willing to unlock developers boxes was just the tip of the iceburg of a massive buracracy, the project ended up being a huge failure and by the time I left half of the IT department (not just the project team) had quit.

Just my 2 cents

Answer 7

Yeah. Leave. If your organization is not willing to give you the normal tools that any normal professional programmer should be able to use, then it's time to up your networking skills and update your resume.

Answer 8

Sounds like they're doing you a favor. Your code is guaranteed to run as a normal user, doesn't try to write to program files or other sensitive directories, is aware of what issues virus scanners bring to the table, and can handle other issues you wouldn't have normally encountered until installing your apps on a client machine.

As for no access to SO, I'd quit.

Answer 9

Work within the (hostile) rules and give up, quit and find somewhere more enlightened or try to change the organization, your choice.

If you decide to try and change things don't go against IT alone, that will just make you the "trouble maker" and you will never get anywhere, try to get support from your boss and other developers - if you can't get support then you may be better off looking for a new job.

Answer 10

Our workplace required a full virus scan every day, so in the morning, when I hooked my laptop up, it was a 2 hour wait before I could do work.

I finally found a solution. MSVC 6, has a built in debugger. I went into task manager, and picked the mcaffee scanner process, and told it to debug. This fired up msvc6, and the scanner froze at a breakpoint. I hit reset, and the problem was gone. About 6 months later they removed the policy and all was good.