Virtual Pair Programming

VirtualPairProgramming is PairProgramming in which the two programmers are not in the same room, or even on the same continent.

Known Tools:

CollaborativeEditing (http://en.wikipedia.org/wiki/Collaborative_editor):

All you need is:

http://www.uk.research.att.com/vnc/index.html

[1] VirtualNetworkComputing (Cross-platform display serving)

-- MichaelKlein?

(and a nice network connection :-)

Using the screen solution, nice network connection isn't as much of an issue. Text signals are much smaller than gui signals... -- JeffBay

We tried using this to share a single piece of hardware between two developers. It didn't work very efficiently. (Win)VNC was very slow, even on a 10MBit LAN. If you have VisualStudio open, it's easier to walk over and do it manually or phone an operator close by. VisualStudio has a tendency to repaint the screen continuously as you move the mouse around. VNC is also very mouse heavy, as common keys aren't available (probably because it's cross-platform). I've also tried it across the Internet and that was very slow, although, I admit it was useful if only to administer my other servers. -- SunirShah

Try using TridiaVnc? (http://www.tridiavnc.com). It has a ZlibHextile? encoding that works pretty good over the InterNet and low-bandwidth connections. It also supports password authentication and a bunch of other features. -- JaenSaul

TightVNC (http://www.tightvnc.com/) has an even better compression than Tridia's -- LapoLuchini

The problem here is the Windows server, VNC has to scrape the pixels out of memory, or something. It works pretty well on Unix where it's effectively a dummy X server. Of course, this doesn't fix your problem... -- SteveFreeman

I've done VirtualPairProgramming using (Win)VNC and the telephone. My partner was on 56k dialup (I was on cable), and as long as we kept a maximized text window on the screen, it was usable. We certainly achieved the MentalStateCalledFlow, though it wasn't as efficient as co-located PairProgramming. -- BrentNewhall

Most everyone who has made comments on PairProgramming has felt that voice communication is required.

LukeGorrie has used NetMeeting voice chat from Australia to America with just a small lag.

How about Apple's OS X with iChat voice and SubEthaEdit (formerly Hydra)?

I've used SubEthaEdit along with iChat for PairProgramming a tiny bit. Of course it's not nearly as good as being in the same room, but it's way better than programming alone. One observation: it's actually a drawback that both people can edit and move the selection at the same time. If you give in to the temptation to use that ability, you lose the observer/driver distinction along with the "pair flow" state of mind. -- BenKovitz

Bits Moved from PairProgramming:

Can pair programming work with a geographically distributed staff? Are there tools to support it, like a split windows, with the code in one window and a chat session in the other? With OpenSource, distributed coding is an issue. -- CayteLindner

I've done pair programming with someone in another state. It required two phone lines - one for the modem and one for speaking. We used LapLink? software, but there are other similar packages available. One computer hosts the session, and the other computer displays the session. The only weirdness is that when the "guest" types, the "host" sees the keystrokes (and typos) first. It requires a bit of patience not to comment on mistakes immediately.

I wouldn't use a chat session to replace oral conversation during pair programming. It would create a totally different type of communication from the kind that makes pair programming work. -- SusanJohnson

I have begun close collaborative work with a colleague for both brainstorming design concepts and administrative work (contracts and the like) and have extended it to drawing designs white board style (use cases, etc) and even coding.

We often work via connected workstations (PCAnywhere or other collaborative tools) and telephones with headsets. We find it to be very efficient as we have complementary skillsets as well as a trusting relationship developed over the years. In addition, we have fun together which is probably the real reason why it seems to work.

While we have occasionally sat at the same physical workstation trading off the keyboard, we find it more productive on connected workstations where we pass control back and forth quickly.

Has anyone else worked like this?

-- Don Robins -- San Francisco -- dbrobins@pacbell.net

(moved from PairProgramming)

I've used NetMeeting, NetOp? and Citrix. I've also used pcAnywhere (which is why I found this ref). Sharing KVM (keyboard, video, mouse) from adjacent desks is better than sitting crowded around the same desk even when pair-programmers were colocated and makes occasional remote pair-programming much more natural. When pairing from two different sites, phone headsets (essential) and shared KVM makes for a very productive pair-programming environment.

A pleasant side-effect is that you become much more skilled at handling complex remote interactions with customers.

For lengthier text of my views on this, search comp.lang.smalltalk for messages containing "Niall Ross" and "NetMeeting" and/or read my reports in the ESUG 2001 and Smalltalk Solutions 2003 conference reports (reachable from http://www.esug.org/).

- Niall Ross, eXtremeMetaProgrammers

WantAds

I'm looking for someone to try VirtualPairProgramming with me via Emacs multi-display, and speakfreely voicechat, using the PythonLanguage. SpeakFreely is not linux specific, but Emacs on win32 is rare.

And perhaps more importantly, Emacs on win32 is unable to understand the make-frame-on-display function. (I've tried it in my office, both with and without running an X server, but the new display always seems to pop up on the terminal that it's called from. And running it from my Linux box trying to pop a window up on my NT box just fails totally. :(. ) -- BlakeWinton

Can someone suggest other possible configurations? -- ShaeErisson

I've had success using xemacs running on a linux box and using ssh -X to connect to that box from a cygwin running XFree86. In that case make-frame-on-display with the appropriate DISPLAY set worked for me. -- FrankHorowitz

Run an X server on both machines and then build a version of Emacs that runs on Win32 but uses X for its display. The cygwin libraries allow you to do this. -- NatPryce

I've recently had success using screen and console emacs. I've also discovered that ssh can forward local and remote ports through the encrypted channel between two machines, thus allowing two people to work together with both shared text and voice as long as one can ssh to the other. See the ssh man pages for details on how this works (specifically -L and -R). -- ShaeErisson

Add skype into that mix, Shae, and it's a nearly ideal config for people who can't collocate. I've added a page on my own wiki for how to setup multi-user screen. These instructions take advantage of the ACL type fucntions of screen to allow multiple user ids to connect to the same session. http://www.lathi.net/twiki-bin/view/Main/MultiuserScreen -- DougAlcorn

I've done similar things with remote locations before via a LAN/voice connection. Typically in a corporate environment where access to a common resource is both possible and fast. Sharing the file is typically either browser-based (if we're stuck with a web server context) or EMACS-based (if we're lucky enough to watch someone else doing the typing). In EMACS, enabling auto-revert-mode allows one end to watch / navigate changes as they are typed in at the other end. If the VoiceFlowControl is working well, editing responsibilities could shift between different parties on the [conference] call. Quite workable given timezone and mindset differences. Works pretty well for technical meetings as well, though this is probably just a really cheap form of desktop video conferencing. -- FrotzFaatuai?

We wrote a little program to share a UNIX session. From there you can share your favorite editor as long as it's text based. Emacs 21.1 has colours in console mode so it's not that much different from under X. For voice we use SpeakFreely. -- ChristianTaubman

I've used screen (and vim) to do this several times, simply by connecting to an existing session with screen -x as the same user (normally root on the box of question). Screen also let's you share a session with a separate unix user, C-a :acladd stain in foo's screen will let me (stain) do screen -x foo/ (requires suid-root screen). If using irc or some other chat program for communication, avoid trouble by not running irc in the same screen. Note that you will be giving full shell access to the other user. See the man page of screen(1) for security aspects. -- StianSoiland

Multiple pointers

Currently using Windows' Remote Desktop sharing. Can someone tell me which of the above solutions implement multiple pointers, so that you don't have to fight over control of the mouse?

SelfLanguage has that, even shows username next to the pointer, looks very cool. It's language specific though. --ShaeErisson

Same for SqueakSmalltalk. -- LaloMartins

A distinction should be made from issues of VirtualPair? (Particle) Production and QuantumComputing / QuantumProgramming? see http://www.astronomy.net/forums/bigbang/messages/86.shtml?base=30

I'm experimenting with remote PairProgramming with a few others, partly out of necessity but more than anything to see what we can learn and whether there are some different techniques that can make it effective. After all, we're not talking *as* effective as real PairProgramming, just more effective than remote programming with a partner.

A few things we've learned so far:

1. Our issue tracker (based on ZopeApplicationServer, custom built, hoping to rewrite in Python instead of ZClasses and release to the world) is highly effective for managing the stories for a distributed development team. All members of the team have worked together in one place using a similar tool so it is very comfortable to us.

2. Wiki pages rule as a simple, convenient form of KnowledgeBase?. Combined cleanly with the issue tracker we are all set on that front.

3. Jabber is interesting. We just installed jabberd on the server a week ago and have been playing with the various free Win32 clients. Not too bad, although to date we've managed only one online scrum (took 30 minutes instead of 15, but we all got to attend our underwear which was a bit of a change from the in-person scrums) and a few halting pairing sessions. So far the only real limitation has been availability of the programmers, not limitations in the tools. We expect to encounter those shortly when we get more serious. I'm not sure how far you could get without either a tool to mirror desktops on each other's machines, or an editor that allows remote collaborators to work on the same file.

4. Interested in experimenting with cameras and audio, ala NetMeeting or something, but too little time to go that route yet. My own feeling to date has been YAGNI but I'm sure there will be real benefits once we try it.

-- PeterHansen

I'm a stray who just wandered in, who has never done PairProgramming, but I have just learned about a very nifty app for Mac OS X called "Hydra", which does allow simultaneous collaborative editing of a document, either over the Internet or LAN. It's even possible to share a document by including a URL to it ("hydra://domain.subdomain/document") on a webpage. Hydra just won an award from Apple as one of the best new software products. Free for download at: http://hydra.globalse.org/

-- Leigh Williams

Hydra is now SubEthaEdit.

How about remote "pairing" when using a WikiWithProgrammableContent? (yes they exist) And you don't have (or particularly want) a simultaneous view of the screen using VNC or whatever? You are still more or less all looking at the latest post. Would it work to just let person 1 edit, then keep refreshing till you see person 2 (or person 3) make a change, and keep alternating? Similar to how normal wiki pages change usually there seem to be only 2 or three people changing pages at a given "session" (though person 4 and 5 may change it later).

I've had some very successful remote pair programming sessions using voice chat and Hydra - I would go so far as to say there wasn't too much of a difference between pairing that way and pairing for real.

-- ChanningWalton

It's a terrible shame Hydra (apparently now called SubEthaEdit) isn't available for a *NIX or Windows. Anybody aware of any really similar software that isn't restricted to Mac OS X?

-- JosephRiesen

FYI, other options are listed at the top of this page.

Recently (December 2004) on the XP email list, some technology and practice suggestions about remote PairProgramming were offered.

The two main technical problems involved are voice communications and shared control of a computer.

People problems also crop up:

InstantMessaging, InternetRelayChat, or something similar, is useful for coordinating teams: seeing who is available to pair, grabbing the integration token or machine, etc.

BrianButton:

We've found that our experience has been pretty good so far. We're using skype for voice communications along with headsets. I have a USB headset with mic and I just wear it and talk. We share code through VNC, which is nice because we can each take control by just moving our mouse or typing. We've had to introduce a small protocol to prevent us from both trying to type at the same time, but that's about the only formality we've needed.

All in all, I think it has worked really well. I've paired with PeterProvost a few times in person, so that may be making it easier, and I've known him for several months, which may affect this as well. There is a feeling of trust and respect that we have for each other that is probably making the narrower bandwidth for communication less of a problem. If I were doing this with a person I didn't know yet, and we didn't have that trust and respect, I suspect that it might be harder to gain remotely than it would be in person.

For us, it is probably almost as good as pairing in person. The tools feel natural to use, and we're working through a difficult problem but making progress.

The one drawback I've noticed is that it is easier for me to get distracted by the web or email like this than it is in person. I find myself just listening to Peter talk about what he is doing while I'm checking email or something. I know I should be intently watching the shared IDE, but sometimes I wander. This is a discipline problem I need to address myself.

PaulFriedman:

For the project on which I am working now, the team has been remote pair programming for the past eleven weeks - and everything that Brian wrote above is spot on, esp. the distraction thing.

IMO, the focus when pair programming in person is much sharper than when pair programming remotely. This is something definitely to watch out for and I notice it occurring more often with pairs that are more unfamiliar with each other.

We too use skype for voip and vnc. The only addition I have is that if security is an issue we set up an ssh tunnel with stunnel following the directions found here: http://www.securityfocus.com/infocus/1677.

IljaPreuss?:

I've recently used skype, too, but in conjunction with Sobalipse (an Eclipse plugin). It allows you to share editors with remote partners, so that you can both type at the same time (and see in which line the other person currently is). You can also put yourself into "watch mode", so that the tool automatically follows the remote partners actions. It also has a tool to share part of your screen for watching and pointing. Works quite nicely.

JimLong?:

I agree with the other comments so far mentioned, especially that having a bit of co-located time to pair helps with the remote pairing. I have a couple of additional points:

GregHouston:

A friend and I wanted to learn and practice some remote pair programming. We tried pair programming on TopCoder http://www.topcoder.com/ using the player id tandem-grog. I wrote a short blog about the experience and tools used at http://ghouston.blogspot.com/2005/07/remote-pair-programming-on-topcoder.html

A couple of devs on the XCB OpenSource project used Gobby to remotely collaborate on a script to split a repository. They described the development process as "insanely effective".

See also: DistributedSoftwareDevelopment

CategoryPairProgramming

EditText of this page (last edited June 7, 2013) or FindPage with title or text search