The Practicalities of Distributed Pair Programming

In the current market it becomes more and more likely that developers in the same team will not be in the same physical location. This is caused by outsourcing, but also other reasons like ever increasing focus on open source projects.
In a distributed scenario pair programming has huge benefits over meetings and sending comments on issues around. It is (still) the fastest way of sharing detailed information between people, and it actually gets the job done where a meeting does not.
The added benefit of pair programming in a distributed team is that it bridges the gap between the local team and the remote team that is caused by the fact that informal communication is impeded. Research has shown that pair programming works in distributed teams [1]. The challenge is to find out how to make it work for you.
In my previous blog on Pair Programming I focussed on the different styles that I see in my daily practice and ways of improving the dynamics in a pair. This applies equally to colocated pair programming and distributed pair programming. At my current client I bumped into the issues particular to distributed pairing, so in this blog I will outline habitual and technical prerequisites for successful distributed pair programming.

As I touched upon in my previous blog there are a couple of things you need in order to to pair program with a remote pair. I will list them here more completely.
Hardware
You need your hands free and a good audio connection, feedback loops and background noise are killing. A good headset and webcam are dead cheap in comparison to the costs of a bug caused by miscommunication.
Network
You need to be able to share a screen at reasonable resolution, so a good network connection is essential. I’ve found that if the lag time between screen and sound goes above 1 seconds it suddenly becomes much harder to make sense of what the other guy is saying. As a driver you don’t notice this immediately, so it can cause a slip from Rally style into Tour style for the navigator.
Software
There are many ways to share your screen. Try a few and make sure the whole team is comfortable with a few options. I like Yuuguu because it is platform independent, but Mikogo isn’t bad either. I don’t like IDE plugins as a primary option because they disallow quick sharing of other tools like the commandline or a text editor. This is explicitly not to dismiss dedicated sharing tools entirely, because they are much faster and support native resolution by default among many other things that simple screen sharing does not have [2].
A typical pairing session in a colocated situation is established very easily. Establishing a remote pair takes a bit more effort. This is why many teams experience the gap between remote and local team. Pairing statistically happens more often locally and team members feel left out of what happens on the other side. To bridge the gap favor distributed pairs over colocated pairs.
To establish a distributed pairing session it is great if you can arrange it at the standup (provided that you have a good distributed standup in place). If you can’t you will have to establish it in some other way. One way that I liked a lot is to have an open team chat (you can use irc for this or another solution that is available) in the channel you shout if you’re looking for a pair and things get arranged from there. There is software dedicated to pairing that also supports pair finding.
Once you have established a pair you need to take a bit more effort to keep things arranged:

• Be very clear about duration of breaks
• Plan what is going to be done in the pairing session and be clear about when it’s over
• Explicitly take time differences into account in your planning

All these points mitigate the risk that one part of the pair ends up idling waiting for the other part to return from his coffee break, which turned into a short meeting, which ended with that person packing up and leaving for the day. Trust me it will happen…
With these precautions in place distributed pairing can actually be more effective than local pairing in my experience. There is something to say about strict negotiations about whom is touching the keyboard at a given time…
Final advice
Distributed pair programming is even more tiring than pair programming. Don’t try to do it 8 hours per day. The nice thing about offshore teams is that they usually live in a different time zone. This means that the overlap (core hours) is less than 8 hours. This gives you plenty of time for local pairing and reading email and that is fine, you need that time.
As I mentioned in my previous post it is important to make sure you’re well rested, fed and hydrated before you dive into short runs.
Have fun and share your experiences!
References
1. https://collaboration.csc.ncsu.edu/laurie/Papers/TR02-010.pdf
2. https://www.jucs.org/jucs_15_16/understanding_tools_and_practices