Reasons to Use a VM For Development

Question

Background:

---

I work at a start-up company, where one team uses Virtual Machines to connect to a remote server to do their development, and another team (the team I'm on) uses local IIS/SQL Server 2005/Visual Studio installations to conduct work.

Team VM is located about 1000 miles from Team Non-VM, and the servers the VMs run off of are located near Team VM (Latency, for those that are wondering, is about 50ms).

A person high in the company is pushing for Team Non-VM to use virtual machines for programming, development, and testing.

The latter point we agree on -- we want Virtual Machines to test configurations and various aspects of the web application in a 'clean' state.

---

The Problem:

What we don't agree on is having developers using RDP to connect to a desktop remotely that contains Visual Studio, SQL Server, and IIS to do the same development we could do locally on our laptops.

I've tried the VM set-up, and besides the color issue, there is a latency issue that is rather noticeable, not to mention that since we're a start-up, a good number of employees work from home on occasion with our work laptops, and this move would cut off the laptops. They'd be turned in.

---

Reasons to Use Remote VMs for Development (Not Testing!):

Here are the stated reasons that this person wants us to use VMs:

• They work for TeamVM.
• They keep the source code "safe".
• If we want to work from home, we could just use our home PCs.
• Licenses (I don't know what the argument is, only that it's been used).

---

Reasons not to use Remote VMs for Development:

Here are the stated reasons why we don't want to use VMs:

• We like working from home. We get a lot done on our own time.
• We're not going to use our Home PCs to do work related stuff.
• The Latency is noticeable.
• Support for the VMs (if they go down, or if we need a new VM) takes a while.
• We don't have administrative privileges on the VM, and are unable to change settings as needed.

What I'm looking for from the community is this:

What reasons would you give for not using VMs for development? Keep in mind these are remote VMs -- this isn't a VM running on a local desktop. It's using the laptop (or a desktop) as a thin client for a remote VM. Also, on the other side of the coin: Is there something we're missing that makes VMs more palatable for development?

---

Edit: I think 'safe' is used in term of corporate espionage, or more correctly if the Laptop gets stolen, the person who stole would have access to our source code. The former (as we've pointed out, is always going to be a possibility -- companies stop that with litigation, there isn't a technical solution (so far as I can see)). The latter point is ( though I don't know its usefulness in a corporate scenario) mitigated by Truecrypt'ing the entire volume.

Answer 1

I think the latency alone would put me off.

Not mention a number of other networking issues: what if for some reason you can't connect to the VM (a router or link down somewhere between you and it, or the server goes down, or whatever reason).

Plus a laptop is much more portable.

Answer 2

As stated by you and others - the issue of "free productivity" by people taking laptops home is a done deal - that with the latency is enough.

As a manager I would also like to keep the developers happy - if they want laptops and no VM for primary development - no problem.

VM has its place - but IMO not as a primary dev environment.

Answer 3

The biggest argument I'd put across is that using a VM is going to adversely affect your productivity. There's a reason why we as developers have fast machines, dual monitors etc. Even working on a machine that is lacking in RAM can be bad enough to knock you "out of the zone" as you have to wait for the machine to catch up with you.

Specific arguments I'd address are:

They work for TeamVM.

Have TeamVM tried working in a non-VM way and if so, what was the productivity difference?

They keep the source code "safe".

I'm not even sure what your managers think this means. Are they referring to having the actual code out in the wild on your laptops?

If we want to work from home, we could just use our home PCs.

Surely this would make your work more susceptible to theft, viruses etc? Especially in a home environment where multiple people have access to your machine.

Licenses (I don't know what the argument is, only that it's been used).

This surely is a red-herring? If they want you working from home on your home PC's they're going to have to pony-up the money for licenses for those machines anyway?

Answer 4

Latency is a big big No! I use VM for manual testing and automated testing, also trying to keep a VM for fallback (if main system goes down then I can just fire and continue).

IMHO RDP is a terrible idea, developers should be hassle free and every seconds matter.

Answer 5

I use a combination of the two, although most of my VMs are running on my local machine. My default position is to use my base machine for performance and no VMs. However, sometimes it is just much easier to develop against the virtual environments. I mainly do this when...

1. I need particular software or services installing that I would prefer not to have, or cannot have, on the base machine. eg. MOSS, Microsoft CRM, Exchange, Oracle, DB/2, (we are generally an MS house) third-party services that I don't trust or that are a pain to uninstall.

2. I need to emulate a networked environment with multiple machines, especially if I need a domain controller or an Exchange server.

3. I am testing against multiple configurations and operating systems.

Answer 6

At our shop, the way we work is as follows:

• Visual Studio installed locally on the developers workstation.
• VM for each developer, generally for each client they work on, running the server applications (SQL, IIS, CMS/MOSS/Commerce Server/etc).

This generally works ok for us - we map a drive to the VM on the desktop and work locally, but against the remote file system etc.

The only real pain is debugging - for VS2008 you need the Remote Debugging app running on the server and you have to connect to the process rather than just hitting F5.

I'm not sure about this arguments for using them:

• They keep the source code "safe".

If you've got source control in place it doesn't matter if a machine dies, unless by "safe" they mean "stays on our network, doesn't get left on a train where anyone might find it".

And as for:

• If we want to work from home, we could just use our home PCs

Unless you've got a big monitor at home, developing from there is going to be fairly painful, and if you've got a large monitor setup, you've probably got a machine to go with it that can run Visual Studio, and then my way of working will work from home - connect to the office VPN, map a drive, and you're away.

Answer 7

I use virtual machines for development, I just don't edit code via VNC/RDP during my normal flow of work.

I have to write three kinds of applications, Linux, Windows and Portable. So, I typically have a Linux VM and Windows VM running on my development desktop enabling me to compile and test the work on either platform. Sure, when running the program via RDP or VNC its a little fuzzy when wondering if the latency is in the application, but if I'm using a VM I'm not at the stage where I really care about that yet.

I would tell your boss that editing code via RDP is a lot like trying to drink an ice cold milkshake through a hypodermic needle. I understand the paranoia, but this is not the solution.

Answer 8

We don't have administrative privileges on the VM, and are unable to change settings as needed.

This is a big red-flag for me. I wouldn't even consider working at a company that doesn't give devs admin access. Your company machine can be locked down, but development often requires tweaking and playing with machine settings.