Developing via Remote Desktop

Jason picture Jason · Feb 1, 2009 · Viewed 15.3k times · Source

Has anybody any successful remarks about having a team working via Remote Desktop?

In many workplaces, we put end users via Citrix and the applications on a central, powerful server. Sometimes the clients are in the same building as the server, but often, they are remote.

There could be some huge benefits for me to put my developers on Windows XP or Vista instances running on a couple servers with Hyper-V.

I'm worried that RDP/RDC via the internet would be too slow for somebody to be able to develop efficiently.

I'm sure I can hear plenty of bad things about it... are there any people out there that have had success?

Answer

ConcernedOfTunbridgeWells picture ConcernedOfTunbridgeWells · Feb 1, 2009

I have seen a situation where the attempt was made to do this with a sattelite office. It was done for a java development team using various java IDE tools. The result wasn't regarded as a success, and the company brought the team back into a central London office at considerable expense.

For someone doing this on a day-in day-out basis on interactive software, the result isn't really very pleasant. For something that mainly uses text-based tools such as vim and unix command line tools, it works somewhat better. At one point I had XVNC going over a 128 Kbit DSL link (of a type that was prevalent in New Zealand at the time) and could do work on an Oracle-based data warehouse at a remote location quite readily. The level of interactivity required by the tooling made them much less sensitive to the slow link than a Windows-based IDE.

So, I'll invoke the 'it depends' argument with some qualifications:

  • I would not recommend it for a modern IDE, and certainly not for something heavily graphical like Dreamweaver, BI Development Studio or Informatica.

  • For a textual environment like traditional unix development tools it could probably be made to work quite well. These user interfaces are much less sensitive to latency than a direct-manipulation user interface.

I'm something of a believer in the 'best tools' principle. Going out of your way to give a second-rate user interface to a development team will give off negative signals. The cost saving from doing this is likely to be minimal and it will annoy some of your team members. Even if it can be made to work reasonably well you are still making a value statement by doing this. Weigh the cost saving against the cost of replacing one or more of your key development staff.