It's budgeting time and Corporate is balking at the cost of replacing a coworker's machine who is due for it, needs it, and deserves it.

Our group is a small ISV/SAAS that exists as a division of a larger media group. We are not a cost center, we make money, even this year. We are owned by a mid-size media group whose business model is quite different, and seems driven only by reducing costs.

Our software stack is Visual Studio 2008, SQL 2008, on Windows Server 2008 (so that multiple root websites can be hosted and debugged on each dev's machine). Our target hardware is 3GHz quad-core workstation, 4GB RAM, and RAID 1 mirrored hard drives so that we are protected against the productivity loss of losing a developer hard drive.

Corporate wants to give us a couple powerful, but hand-me-down, decommissioned servers, and then each developer would have a virtual workstation on that server. The computers sitting on our desktops would be dumb terminals at $400-500 each.

I'm trying to be neutral but I doubt it's hard to discern my bias. I'd like to see real developer reactions to this, and I figure this is the best place to get that.

Please include arguments for or against, evidence if you've seen this tried and how well (or not) it has gone.

+5  A: 

Aside from all of the givens (perfomance, disk space, etc...):

I would be OK with this as long as I still had multiple monitor support.

Without that, it is a no-go.

John Gietzen
Absolutely! Modern IDEs are absolute screen-hogs. And even if you are of the Terminal/VI/Emacs/make conviction, you'll still want all the screen real estate you can get.
Joachim Sauer
+8  A: 

This sounds like a well intentioned idea, but:

In my experience you need multiple cores, lots of memory, and fast disks to be productive in today's modern IDE's. I don't see that happening in a virtual environment with any economy. Individual boxes are still better.

It's also an issue of control. In a virtual environment I can imagine all kinds of restrictions. Will you still be able to install your own tools, for example?

Ultimately, it's misguided. If this idea increases build times by any substantial amount, any savings in hardware will quickly be erased by lost productivity. Conversely, money that is spent on decent individual machines for developers will quickly pay for itself over and over in reduced build times.

Good quality individual machines are an investment, not a cost.

Robert Harvey
+7  A: 

Development is disk-bound, i.e. you spend your time waiting for builds which is a disk-bound process most of the time. If you're all sharing a machine build times will become much worse.


I assume you have machines already for SVN / TRAC, your Continuous Integration server, product demos, testing, etc. and that the only possible use your team could make of these servers is for personal VMs.

Ewan Todd

I do many things that peg my processor at 100%. Compiles certainly achieve this. Now imagine having to share that processor with 10 other developers. The loss in productivity will become quite apparent. If you have a multi-core PC, this won't be as painful. Get an Intel i7 and you probably won't even notice it when 8 people are logged in. Most programs (including my compiler) can't use more than 1 processor anyway.

That said, it's a viable solution to reduce costs. I used to work at a company who has since switched to these dumb terminals. It works fine. My university had HP UNIX machines that were dumb terminals. They logged into a server that split up the processor ownership among however many people were logged in. What people would do is log into a server and check the number of people logged in. If there were too many, they'd search for the next one, because build times are noticeably slower. I'd never log into the easy to remember server names. =)

It definitely works, but also reduces productivity due to longer build times, especially when multiple people are building at the same time. Since productivity is such a difficult thing to quantify, it might be hard to argue your point.

Jeff Lamb

Graphics acceleration might also be an issue if you need to do anything with animation, video, or image editing. You can't really test video playback through an RDP session since the framerate and/or color depth isn't high enough.

+1  A: 

Our team is developing on remote server (no GUI stuff, plain old vim) for quite some time without problems. Granted it requires rather powerful server and sometimes is starts to be bit on a slow side if everyone start to compile at the same time.

But as a bonus you are very mobile in terms where you can develop from (we all are having laptops) be it in office, home, sunny beach (last one was probably overstatement).

Bute yeah, that might not all work well for graphics heavy apps of course.

Aleksei Potov
... and this server would have to run a bit more than vim! Visual Studio isn't exactly lightweight!
Matt Breckon
Actually, compared to Eclipse...
John Gietzen
I had quite a success running X-Server locally and running Eclipse on remote machine over local network, so please... :)
Aleksei Potov
+3  A: 

Basic failure to understand what a developer box is actually doing much of the time:

When building its chewing through processor and disk - especially disk. When testing you're talking about having one or more instances of Visual Studio running (once you get past two things start to get interesting), database server, website/services plus all the other stuff (browsers with a lot of tabs open, notebook software, and heaven only knows what else) all spread across multiple monitors (at least two). Lots of cores, lots of memory please!

I can quite happily accept that there's an argument for virtualisation - a good dev box should be able to host multiple, concurrent VMs in order to isolate some of the above and to provide "clean" environments for testing. Note that that's the box for ONE developer hosting multiple VMs solely for the benefit of that one developer...

We already do use Microsoft Virtual PC to host multiple virtual environments for testing, including SUSE Linux for the Postfix MTA and SOLR site search, Windows 2000 with a clean copy of IE6, and multiple installs of XP with different editions of IE we support.
(that is, on our local dev systems)
That's an argument in your favour...

Regardless of performance, at my company we are moving to laptops as developer machines. The main advantage is that developers can bring their computers to meetings, conferences, etc. Also being able to sit next to a colleague when you're helping him with a problem, and having your own development environment available, is very valuable.

Hmm, I'm not convinced - the kind of machine I want to work on (at my desk) and the kind I want to carry round are rather different - decent horsepower in an adequately small package is expensive and if you do otherwise you have to compromise on something else (and if its portability you defeat your basic argument).
You're right you have to compromise. But you can still get a good developer laptop for a reasonable price. My laptop is powerful enough to do development work and portable enough to put it in my backpack. It doesn't have to be extremely portable, because it sits on my desk most of the time. And you're right that desktop machines are more powerful for the same price. But for that extra money you get portability, and for me that's valuable.Ofcourse if money is no objection at all, you should get a powerful desktop machine AND a small laptop, but I don't have that luxury.

It sounds like your group is not offering the solutions that you have considered in a well documented format, otherwise corporate would not be shoving decisions down your throat. If you have a documented process for development, corporate might want to discuss changing the process with you, but as soon as you say, "this change would break our process and we would have to retool our development workflow", they will see the pain of the $$ in reworking the process and most likely back off. That said, once your process is documented, you should internally be ruthless about trying to make it more efficient and cost effective, and have an open mind about corporate's suggestions.