The more you lock down the environment the less productive developers are.
1. What you must strive to achieve is a healthy balance. Which will prove more productive, adding an IT person and easing up the restrictions or adding a developer? In an NT/2000 developer environment I have found that anywhere from 1/30 to 1/50 is a nice balance.
2. Try to have a well-organized testlab for server and client development, you can install 4 operating systems on each machine and make sure to have images of the partitions. You can store your images on the network, on the hard drive or on a bootable CD. The person responsible for the testlab should not report to IT but rather to developers or testing but with good ties to IT (it might be wise to seat the person with the IT department). The testlab should be on a separate network from a firewall, have its own fileserver and DNS server. In many cases it is a good idea to install some kind of remote control, whether it is a KVM on CAT5, IP or a software product. Try to refresh images on regular bases (once a week), this will force the developers to keep track of dependencies and installation procedures.
Testlabs requiring incoming Internet traffic should always be on a completely separate DMZ (service network) behind a firewall, developers should have no physical access to this network but remote control is a good idea. Developers will have to specify exactly which services they will be running (HTTP/DNS/SMTP) and filtering is required for inbound and outbound traffic, this network should not be able to initiate a connection to the internal network under any circumstances.
3. Create an SLA (Service Level Agreement), this will prove very important when a developer machine rolls over and plays dead. Make sure to make it as clear as possible that any data stored locally will not be recoverable when a system plays dead, you can make exceptions but it must be clear that you are doing this out of the kindness of you heart J. You should also make sure to notise the supervisor of that particular developer that he/she destroyed the machine, it will help to install the operating systems from a partition image since that will ensure all installations are exactly the same. If a machine plays dead (software problem, not hardware) the developer is 100% responsible and if this occurs frequently the supervisor of that developer should take actions to solve this problem since it is reducing productivity.
4. Create a list of categories users fit into and which software each of those categories requires. The person responsable for this is usually the CM(Configuration Manager), he/she should have experience in software developement and administration, be well informed and current on software developement tools. If a developer wants to use a certain tool the CM looks into wether the company wants to use this tool, if there is another tool being used which does the same thing and the pricing. This will help to keep a flexible standardized development enviroment. Users can install any software they like but they can not develop on any software not approved by the CM!
Slashdot Mirror
To put it simple
The more you lock down the environment the less productive developers are.
1. What you must strive to achieve is a healthy balance. Which will prove more productive, adding an IT person and easing up the restrictions or adding a developer? In an NT/2000 developer environment I have found that anywhere from 1/30 to 1/50 is a nice balance.
2. Try to have a well-organized testlab for server and client development, you can install 4 operating systems on each machine and make sure to have images of the partitions. You can store your images on the network, on the hard drive or on a bootable CD. The person responsible for the testlab should not report to IT but rather to developers or testing but with good ties to IT (it might be wise to seat the person with the IT department). The testlab should be on a separate network from a firewall, have its own fileserver and DNS server. In many cases it is a good idea to install some kind of remote control, whether it is a KVM on CAT5, IP or a software product. Try to refresh images on regular bases (once a week), this will force the developers to keep track of dependencies and installation procedures.
Testlabs requiring incoming Internet traffic should always be on a completely separate DMZ (service network) behind a firewall, developers should have no physical access to this network but remote control is a good idea. Developers will have to specify exactly which services they will be running (HTTP/DNS/SMTP) and filtering is required for inbound and outbound traffic, this network should not be able to initiate a connection to the internal network under any circumstances.
3. Create an SLA (Service Level Agreement), this will prove very important when a developer machine rolls over and plays dead. Make sure to make it as clear as possible that any data stored locally will not be recoverable when a system plays dead, you can make exceptions but it must be clear that you are doing this out of the kindness of you heart J. You should also make sure to notise the supervisor of that particular developer that he/she destroyed the machine, it will help to install the operating systems from a partition image since that will ensure all installations are exactly the same. If a machine plays dead (software problem, not hardware) the developer is 100% responsible and if this occurs frequently the supervisor of that developer should take actions to solve this problem since it is reducing productivity.
4. Create a list of categories users fit into and which software each of those categories requires. The person responsable for this is usually the CM(Configuration Manager), he/she should have experience in software developement and administration, be well informed and current on software developement tools. If a developer wants to use a certain tool the CM looks into wether the company wants to use this tool, if there is another tool being used which does the same thing and the pricing. This will help to keep a flexible standardized development enviroment. Users can install any software they like but they can not develop on any software not approved by the CM!
That should get you started
Jarl