Without realizing it, I have been part of a war. Like most wars, this one has many battle-fronts and is often overflowing with testosterone. This is the war of development client baselines. Every developer I have ever known has the tools they like best starting with the Operating System right down to which debugger or obfuscator they prefer. There are generally two schools of thought…
‘Load what you want… as long as the code gets written it will all work out in the end.’
We all know where this ends up… In a word… Chaos! For years I watched developers argue over the choice of VI, EMACS, and/or Notepad and it was a little ridiculous and certainly a waste of time.
While this approach may work in college it just isn’t realistic in most professional development environments today.
- Corporations are trying to protect intellectual property and secure networks. This often leads to standardized operating systems, security protocols, Malware protection, Timecard applications, etc…
- In a team environment you really need to be able to work and communicate in a fairly consistent manner, this often leads to common source control tools, IDE’s, etc…
- This approach can often lead to a lot of rabbit trail debugging efforts because one of the developers used something to make their product work that did not exist under source control or in the larger development/test/production environment.
- This approach often lacks good disaster recovery procedures and we all know that development systems can become unstable at the worst times.
The other common school of thought generally goes something like this…
‘All developers shall only load the approved software list and shall not work outside approved baselines at any time.’
We all know what this means… In a word… Micro-management! I don’t want to be too harsh, because in some cases this kind of restriction is necessary. I like to try and remember that Software Engineering is a creative process and I believe developers need a little room for exploration.
- Depending on how it is handled this type of approach can become very inflexible and rigid. People can spend an inordinate amount of time trying to get approval to load really basic tools. When I was a systems integrator I watched as a segment of our users spent a year and a half fighting to get WinZip installed on their systems.
- This type of environment often has a good disaster recovery process and can generally be reconstructed more quickly.
- There is generally good Configuration Management.
- This approach often leads to developers that are not happy with their environment and lack a sense of trust and/or empowerment.
- This can be a problem when working with sub-contractors or out-sourcing partners who may not be subject to these restrictions.
If you boil it down, here are the goals…
- Have an environment that is secure.
- Have a disaster recovery process.
- Establish common tools and Configuration Management (CM) over the development baseline from one iteration to the next.
- Have the flexibility to evolve the baseline over time.
- Provide the developers some room to experiment.
For me the solution was virtualization. Working in a sub-contracting environment I was able to establish the following rules.
- The Host System
- All development clients shall be Windows Platforms and have sufficient resources to support Microsoft Virtual PC 2004 or later and Microsoft Team Explorer 2005 or later.
- All development clients shall include a Virus, Malware, and Software Firewall with exception added to connect to project assets.
- All development clients shall be subject to periodic reviews to ensure monthly Critical patch from Microsoft are being loaded.
- Developers can load any legal software they or their companies deem necessary.
- The Virtual System
- All development shall be conducted with-in CM controlled Virtual PC baselines which are versioned and maintained in a central location.
- Maintenance of virtual baselines will be managed by the CM team and shall be updated and published monthly.
- Requests to change baselines will be reviewed every month.
- New baselines can be established to meet emerging requirements and will be assessed as requested.
Essentially, these rules attempt to provide developers/contractors the flexibility they require while providing project managers the CM they require. Virtualization has a lot of side benefits.
- When a system inevitably crashes. The developers are able to reset their development environment by simply copying the requisite Virtual PC files.
- You can easily jump between older and newer baselines to support older products or to work on newer efforts.
- Developers can do any experimentation in Virtual baselines they create for themselves.
- CM maintains virtual baselines based on the number of software licenses they have… For example, since we are a TFS-shop we have architect baselines, tester baselines, developer baselines, etc
This has worked well for us and may help you as well. Don’t underestimate the power of virtualization.
Tags: