- Identifying Development Requirements
- Designing IT Infrastructures to Support Development
- Building Development Infrastructures
Identifying Development Requirements
How can developers and IT personnel reach a common ground? Several "solutions" have been suggested by IT in the past. The easiest is based on using two system partitions on a PC. This gives the developer a production partition (the system that is designed and supported by IT) and a "freeform" partition (the development partition).
Another solution is exchangeable hard drives. The developer has two hard drives: one that's supported by IT and another for development purposes. In either case, the developer must reboot the system to change environments.
IT likes these solutions. They've met their goals, since the production partition remains stabletheir partition is safe and sound. The other...well, it's the developer's responsibility, isn't it?
In reality, these solutions are not without issues for both developers and IT. Two disks or two partitions imply that only one will be active at any given time. This means that only one is active when IT initiates a centralized deployment. This deployment misses the other partition entirely. If the wrong one is active, it's even worse.
Two disks or two partitions also means a major loss of productivity on the part of the developer. Can you imagine? Reboot the system to read email; reboot the system to test code; reboot the system to write a document about the code; reboot the system to check just how this new component worksquite unproductive, wouldn't you say? Invariably, the developer configures this second partition or disk with the tools required to run production softwareemail, productivity tools, etc.to avoid continual rebooting.
This strategy always leads to dissatisfaction on the part of developers and tension in the IT department, which in turn leads to the simplest solution of all: Give the developer administrative rights to the PC. Now the developer is content, but not IT, because they can no longer meet their service level agreements (SLA). Discarding these SLAs for developers is not the answer either. A real answer must be foundone that meets both the developer's requirements and IT's mission.