Note: This blog post was originally written when I was a consultant for OpenSource Connections.
Agile teams should be based on talented development staff with multi disclipinary skill sets. This allows team members to easily trade tasks and keep the iteration moving forward. As a consultant, I have seen and worked in many environments where development staff are very silo’d in their skill sets. In most cases they are very good at what they do, but at various times each team member can become a bottleneck because they are the only person who knows how to do a particular task or work on a certain legacy system.
But multi-disclipinary skill sets are not the only key to fluidly switching people between tasks. You must also be able to change technology or development environments easily as well, and this is an area that I find almost all development environments suffer from.
As an IT leader, when you bring in a team of consultants to augment your team and give their velocity a shot in the arm, you expect them to integrate quickly and be productive right away. And that’s what the consultant wants too. But are you giving them the tools they need to be effective right away? Or do you expect each of them to go through the same development environment setup that you ask new hires to do?
When you hire a new person, perhaps it’s worth the time to have them setup everything about their development environment. They learn about the nuances of your system, and a few days or a week of their time is nothing compared to the long term investment you expect from having them work for you for several years.
When you bring in a consultant, it’s different. You may only expect to have them for a few months, and their time is more expensive then your internal staff. And they are not going to benefit much from the learning experience of setting up a dev environment.
And even for your full time staff, what happens when they have to upgrade their machine a year from now, or their system dies and they have to rebuild from scratch? Do you really want to have them spend another week trying to remember how to get past that one install bug that they encountered a year or more before?
One answer to this problem is to develop code using virtual machines. Instead of having your first developer start by setting up the toolsets and plugins on their machine, have them start with a clean virtual image, using a tool like VMWare Player. Keep a bare bones image around with your basic development tools, or start with one from a similar project. After the developer gets the code started and everything basically working, then they should make a copy of that image and distribute it to the rest of the development team.
A backup copy of this image should also be kept on a network share or external drive so that when you add in consultants, or bring in a new hire, they can get started on code just as soon as they copy the image over to their machine. Instead of spending a week getting everything installed and picking the brain of your development staff, or Googling on obscure error messages, the only time delay is how long it takes the image to copy to their local machine (probably no more than an hour in most cases).
Now you can spend their time where it’s valuable: Bringing them up to speed on the nuances of your code itself, not the right service pack or magic incantations to get the development tools working.
You might be thinking that with cloud computing and languages like Ruby on Rails, shouldn’t this be a non issue? I just pull down the code from svn or github, and I’m ready to go! In my experience, while that is usually the case with relatively small projects or with projects started in the last year or two, it’s not always the case with lots of other code that exists in the world and that we have to work on.
I was reminded of this because of a client I recently worked with is still using version 1.1 of the .NET framework, and so is required to run Microsoft Visual Studio 2003. As part of the project we’ll probably end up doing an upgrade to more recent versions, but we still have work we have to do first. And unfortunately I discovered on my first day on the project that Windows 7 does not play well with Visual Studio 2003. Once it installed, it wouldn’t connect to IIS in debug mode. After doing some googling and seeing that this is a common problem with no easy solution (I tried many of the recommended solutions to no avail), I decided it was time to just get an image of Windows XP going. The rest of the dev team is on XP, but they are not using virtual machines to do it unfortunately.
So I started creating a new XP image under Virtual PC, only to have it started failing on certain files. Even though the install continued, I ended up with an image that could not talk to the outside world and was clearly half-baked.
So then I started over with VMWare Player, and as I write this, my XP image with Visual Studio 2003 already installed is nearly done. 3 days later. Before I start changing code on it, I’ll be setting the image aside to give to another consultant joining the team in a few weeks, so he doesn’t have to go to the same level of pain. I’ll also make sure the client has a copy of that image to make their life easier in the future the next time they bring us in or make a new hire.
Before you attribute the delays I experienced to Microsoft, I’ve seen similar challenges on Php projects and to a lesser degree on Groovy on Grails projects.
Virtualization is great for reducing the size of your server room, cutting down on power bills, and becoming more green. But don’t let it stop there. A little bit of time spent up front on virtualizing your development environment will save you a lot of heartache and expenses later down the road, and make your IT shop much more agile.
