Should developers be limited to certain software for development?

Question

Should developers be limited to certain applications for development use?

For most, the answer would be as long as the development team agrees it shouldn't matter.

For a company that is audited for security certifications, is there a method that balances the risk of the company and the flexibility, performance of the developers?

Scope

1. coding/development software
2. build system software
3. 3rd party software included with distribution (libraries, utilities)
4. (Additional) Remaining software on workstation

Possible solutions

1. Create white-list of approved software where developer must ask for approval for desired software before he/she can use it. Approval would be based on business purpose/security risk.

2. Create black-list for software. Developers list all software used. Review board periodically goes over list.

Has anyone had to work at a company that restricted developer tools beyond the team setting? How did they handle the situation?

Edit

Cleaned up question. Attempted to make less argumentative.

Answer 1

No, developers should not be limited in the software they use, because it prevents them from successfully doing their jobs. Think about how much you are paying your team of developers, - do you really want all that money to go spiraling down the drain because you've artificially prevented them from solving problems?

1) Company locks down the pc and treats the developer as competent as a secretary

What happens when the developer needs to do something with administrative permissions? EG: Register a COM object, restart IIS, or install the product they're building? You've just shut them down.

2) Create a white-list of approved software...

This is also impractical due to the sheer amount of software. As a .NET developer I regularly (at least once per week) use upwards of 50 distinct applications, and am constantly evaluating newer upgrades/alternatives for many of these applications. If everything must go through a whitelist, your "approval" staff are going to be utterly swamped by just one or 2 developers, let alone a team of them.

If you take either of these actions, you'll achieve the following:

1. You'll burn giant piles of time and money as the developers sit on their thumbs waiting for your approval team, or doing things the long slow tedious way because they weren't allowed to install a helpful tool

2. You'll make yourself the enemy of the development department (not good if you want your devs to actually do what you ask them to do)

3. You'll depress team morale substantially. Nobody enjoys feeling like they're locked in a cage, and every time they think "This would be finished 5 hours ago if only I could install grep", they'll be unhappy.

A more acceptable answer is to create a blacklist for "problem" software (and websites) such as Pidgin, MSN messenger, etc if you have problems with developers slacking off. Some developers will also rail against this, but many will be OK with it, provided you are sensible in what you blacklist and don't go overboard.

Answer 2

Limiting the software that developers can use on their work machines is a fantastic idea. This way, all the developers will quit, and then the company won't have to spend as much money on salaries and equipment, resulting in higher profits.

Real answer: NO!!!

Answer 3

I think developers should have total control on applications that they use as long as they can do their job with them. Developers' productivity is directly related to working environment and no one will like being restricted and everyone likes to use software they like themselves.

Of course there should be some standards in terms of version control, document format, etc., but generally developers should have right to use any programs they want.

And security should be developer's concern - company admins should care about setting up proper firewall to protect against any kinds of attacks.

Answer 4

A better solution would to create a secure independent environment for the developers. An environment that if compromised won't put the rest of the company at risk.

The very nature of the development is to create crafty ingenuous pithy solutions. To achieve this, failures must happen.

Answer 5

Whatever they do, don't take away the Internet in general. Google = Coding Help 101 :)

Or maybe just leave www.stackoverflow.com allowed haha.

Answer 6

I'd say this depends on quite a list of factors.

One is team size. If you have a team of half a dozen developers, this can be negotiated whenever a need for some application pops up. If you have a team of 100 developers, some policy is probably in order.

Another factor is what those developers do. If they compile C code using a proprietary compiler for an embedded platform, things are very different from a team producing distributed web or PC software in a constantly shifting environment.

The software you produce and the target customers are important, too. If you're porting the Linux kernel to some new platform, whether code leaks probably doesn't matter all that bad. OTOH, there are a lot of cases where this is very different.

There are more factors, but in the end it all boils down to two conflicting goals:

• You want to give your developers as much freedom as possible, because that stimulates their creativity.
• You want to restrict them as much as possible, as this reduces risks. (I'm talking of security risks as well as the risk to ship non-functioning software etc.)

You'll have to find a middle ground that doesn't hurt creativity while allowing enough guarantees to not to hurt the company.

Answer 7

Of course! If you want a repeatable build process, you don't want it contaminated by whatever random bit of junk a programmer happens to use as a tool to generate part of the code. Since whatever application you are building lasts much longer than anyone expects, you also want to ensure that the tools you use to build it are available for roughly the same duration; random tools from the internet don't provide any such gaurantee.

Your team should say "The following tools are allowed for build steps and nothing else" and attempt to make that list short.

Obviously, it shouldn't matter what a programmer looks at to decide what to do, so the entire Internet is just fine as long as its just-look. Nor does it matter if he produces code by magic (or random tool) as long as your team doesn't mind accepting just that tool's output as though it were written by hand.