Stop saying ”but it works on my computer”

Stop saying ”but it works on my computer”
juli 12, 2013 Fredrik Normén

Often developers and testers are using their own machines for developing and testing software. The local environment can look different, have different tools installed, even different libraries, sometimes some may use technical previews (like me using Visual Studio 2013 preview ;)). When a new team member is joining the team, it may take a whole day or more until he or she has an up and running local environment for the project. Sometimes several developers and testers works with different projects, that requires different versions of tool, libraries etc, all installed on their own local machine. Can result to a lot of mess and problems.

It’s not so strange to hear someone say ”but it works on my computer”.

What if we could check-in all en tools and stuffs we need for a specific project into our source control, and when we work with a project we only gets all the tools and stuffs needed, and have an isolated environment configured and installed for the specific project? Wouldn’t hat be something?. I read about teams that adds the compiler they use with other stuffs into source control, and also setup scripts to solve this problem.

Here is one solution to make it much faster to setup a new environment for both new members and existing members based on the project they are working on, and also remove the words ”but it works on my computer”.

Create a Virtual Machine for each projects. Configure and install it with the correct tools and all the things the project requires. Then make sure each team members copy those Virtual Machines to their local computer and start the correct Virtual Machine for the project they should work with. By doing so everyone will have the exact environment for a specific project. It requires of course a good computer with hyper threading. I live in a world where I hope the customer or employee understands that a computer with the correct performance, will reduce time and cost when it comes to develop software. A cheap computer can result in a higher cost compared to a more expensive computer with great performance (At the end of this blog post I will share my story about how I managed to get my former employee to invest in new computers for the whole team).

Adding Virtual Machines to the source control will probably not be so good, each new branch or history will or can create a copy of a large Virtual Machine. So we need a new kind of ”repository” to store the Virtual Machine for each projects, a ”repository” everyone in the team have access to. It can be a network share, or on a server where it can be accessible over HTTP etc. Make sure you have a good backup plan for the ”repository”!

By adding a Virtual Machine to a ”repository” it would be great to have some kind of pointer to the Virtual Machine to be used in our source control for a specific project. We can for example add a file to our source control that points to the Virtual Machine to be used (from where we can copy/download it, add then add it to our local Virtual Machine environment and start it up). But what if we can make this setup and start up easy for us. What if we could use a simple command like ”start the Virtual Machine associated with the project”?

There is a tool that can help us with this, Vagrant.

Vagrant is a tool to that can help us copy/download, setup and start a Virtual Machine locally with just a few lines of commands. Vagrant uses by default Virtual Box but have providers for WMWare. I hope to see one plugin in the future for Hyper-V.

Just type the command in your command line tool after Vagrant and VirtualBox is installed:

vagrant init MyProjectDev http://…/MyProjectDev.box

Vagrant will now create a local VagrantFile with the information about how to get and which virtual machine to be used. This file can then be checked in into your project source control.

Then to start up and configure a guest machine, just type the following in the command line tool (make sure you have first navigate to the folder where the VagrantFile is located, probably where you have your local source code):

vagrant up

Every team member that should work with a specific project just need to get the latest VagrantFile from source control, and then type ”vagrant up” and they have a guest environment started.

When a new team member joins the team, just install Vagrant and Virtual Box on their machine. Then get the VagrantFile for the project they should work on, and then type ”vagrant up”. No need to install a lot of tools and stuffs that can take a lot of time before the new team member is up and running. Everyone in the team will use the exact environment for the current project.

How did I managed to replace all computers with new better and faster computer?

For several years ago I worked with a large enterprise product. I was frustrated every time I needed to run my code in debug mode. I hated my computer, it was so slow! I often heard team members say the same thing. One day I couldn’t just stand it, so I went over to my boss and told him ”we need new computers, ours are so slow”. The answer was ”no!”. I tried with several arguments but failed. Then I remember something I read in a book, too many leaders have learned to just watch numbers. So I did the following:

I opened the solution we where working on. I measured the time it took to build the solution on the local machine, and the time to start it up. I took an average number of times a team member will do this task every day. I took what I guess was the average developers salary and calculated the cost for just waiting to the project to start up, based on one year.

I went home, did the same thing with my computer at home (a much faster one). Took the price of a new computer times number of developers. I went to my boss and showed him how much new computers will cost, and how much we will save with the new computers compared to the current computers during one year. When he notice how much money the current computer cost in waste compared to investment in new computer. He bought us new computers.

So sometimes numbers must be included.

Summary

By using Virtual Machines, we can setup a development and testing environment for team members fast, and we can make sure everyone uses the correct version of tools for the specific project. By using tools like Vagrant we can make the setup much faster and in an easy way,

If you want to know when I post a new blog post, please follow me on twitter: @fredrikn

0 Kommentarer

Lämna ett svar

E-postadressen publiceras inte. Obligatoriska fält är märkta *

*

Denna webbplats använder Akismet för att förhindra skräppost. Lär sig hur dina kommentardata behandlas.