Remote Pair Programming

Pair programming is a vital aspect of work at the BBC. Yet, on the face of it, it seems to be an awkward fit with remote work — after all, how can you pair program when you are 20 miles away? Nonetheless, both pair programming and remote work are important and the benefits have been known for a long time: pair programming because it ensures high quality code, shares knowledge amongst the team, and promotes code ownership; remote work because it allows greater flexibility, as well as reduced transport spending and stress.

So, it becomes imperative that we are able to combine remote work with pair programming, maintaining the benefits of both as much as we can without compromising either.

This is something we have done on the CBBC Newsround team.

How We Work in Newsround

On my team, Newsround, at the BBC we use Slack’s ability to video call and screenshare when we’re pairing while working at home. This is an incredibly simple process, achieved with three mouse clicks — one to make the video call, one to share the screen, and one to allow the viewer to type on the shared screen. Of course, the technology used does not matter in itself — so long as it allows the ability to talk and screenshare.

What we have found is that Slack’s screensharing functionality allows us to maintain a conversation as if we were next to each other as well as to control each others screens as if we were working from one computer. The way we do this is for one of us to volunteer to screenshare — thereby nominating themselves as the first driver. We change this role somewhat frequently, though perhaps not as frequently as if we were sitting next to each other, alternating screensharer and driver.

What is it Good For?

From remote pair programming, you gain the sum of its parts.

• No stress or tiredness from travel to work
• Fewer office distractions and greater privacy
• Safer and higher quality code
• Knowledge sharing
• Code ownership

All of these things lead to higher productivity and higher team and personal morale. Moreover, from our experience we’ve encountered no issues except for one notable downside.

This is that, at the moment, the technology used (Slack screensharing in our case) introduces some input delay from the perspective of the person not screensharing when they wish to take control of the screen. This is only frustrating, in my experience, when the viewer wishes to type something or use the mouse. The solution, we have found, is to rotate the pair at that point, so that the person who wishes to write or move the mouse is the person screensharing. Thus, the screensharer becomes the de facto driver.

This raises an important issue: there cannot be a monopoly on who shares their screen, for if there is, then the person not sharing will — through frustration with any delay — stop driving. Again, the delay is fine for a few comments, but not if one wishes to drive for any non-trivial amount of time. Much like non-remote pair programming, this requires communication and a willingness to hand control (of not just the screen, but the computer used) over. Fortunately, the actual process of swapping screensharer/driver takes only a moment or two; although it is not as fluid as when two people are sitting next to each other.

One interesting option that would resolve this issue would be to set a certain amount of time — say, 20 minutes — for one person to drive for. After the time is up, the pair swaps driver/navigator. This would have the benefit of clearly defining who is meant to be driving and who is meant to be navigating, making it less of an ad-hoc decision, allowing the remote pair programming to proceed seamlessly.

Conclusion

All in all, remote pair programming works very well, with very few of the benefits of both remote work and pair programming lost. With improvements in the technological capabilities of software allowing remote pair programming, the benefits of remote pair programming will be even greater and more obvious. Until then, if the price to pay is that we are forced to rotate the driver/navigator more often, then that seems a cheap price indeed.