# Remote Pair Programming

## Summary


Pair programming is a practice in which developers work in pairs. When the pair is not sitting next to each other, we call it **Remote Pair Programming (RPP)**. Remote pair programming has the same benefits as pair programming: higher quality software, fewer defects, knowledge sharing, team cohesion, faster delivery, and more.  

The nature of remote working demands the use of suitable tools. Selecting the right set of tools can enable teams get the best out of pairing. There are plenty of tools in the market today (Sep 2021) for RPP.

Since the coming of COVID-19 in 2020 and an increased adoption of work-from-home culture, RPP has become all the more essential.  

RPP is also called *Distributed Pair Programming (DPP)*, a term that appears to be popular among researchers.

## Discussion

### How is remote pair programming different from pair programming?

In pair programming, the pair can point to code with their fingers. In RPP, this is done using the keyboard cursor or the mouse pointer. In some tools, both developers may be able to move their own cursors or mouse pointers. In other tools, there's only one cursor and mouse pointer. The person controlling it becomes the driver. 

In pair programming, both developers are looking at the same monitor. RPP allows more flexibility. The navigator could be checking out other parts of the code while the driver is typing. 

In pair programming, it's possible to share physical artefacts such as printed documents or a whiteboard. In RPP, everything must happen online. It's therefore essential to have tools to perform these activities online. 

RPP can be used for diverse use cases beyond coding: mentoring, hiring, live tutorials, etc. These are use cases where participants are likely to be at remote locations.

We should clarify that sharing code for reviews, making pull requests or using version control isn't RPP. These are asynchronous workflows. RPP happens only when both developers are participating concurrently within the same workspace. 


### What should I look for when selecting a tool for RPP?

Here are some factors to consider: 

    + **Installation**: Often called *Cloud IDEs*, these are tools hosted in the cloud. No local installation is required other than a web browser. Other tools require local installation. Better still are *plugins* that extend popular editors/IDEs with collaborative editing capability.
    + **Cross-Platform**: Some tools may run on Windows but not on Mac or Linux. Plugins are better in this regard. They extend familiar software already available for various platforms.
    + **Editing**: Simultaneous editing by both developers. Copy/paste between systems. One developer can navigate to other parts of codebase or other applications while the other is editing. Editor/IDE agnostic.
    + **Multimodal**: Bidirectional live audio/video streaming. Chat window. Integrated with editor/IDE.
    + **Usability**: Uncluttered layouts. Awareness about what's shared and the current editing context. Automatic turn-off of notifications, thus providing a distraction-free environment.
    + **Performance**: Minimal lag. Supports high video resolutions. Fall back to lower resolutions on low-bandwidth connections. Visibility into performance metrics.
    + **Integration**: Connect to code repositories (GitHub, GitLab, Bitbucket) and other tools (Jira, Trello).
    + **Others**: Security, cost and customer support are also important. Open source may be important for some teams.

### What tools are available for RPP?

There are dozens of tools out there. One way to classify tools is as follows:  

    + **Screen Show**: Only screensharing. Before switching roles, we need to push code changes to a shared repository. Videoconferencing tools such as Skype, Google Hangouts, Google Meet and Slack Calls are examples.
    + **Screen Control/Share**: Temporary remote control of your partner's system. Interactions can lag. Zoom, VNC, Join.me, CoScreen, Tuple, TeamViewer and tmux are examples.
    + **Application Share**: True collaborative editing and hence most preferred. Each environment can be personalized. Developers can use different editors or IDEs. A developer can navigate within the codebase without interrupting the partner. Developers can even edit different parts of the code in parallel. Live Share (with Visual Studio and VS Code), CodeTogether, GitLive, Floobits, Drovio, Atom Teletype, and AWS Cloud9 are examples.Among the Cloud IDEs are AWS Cloud9, Codenvy, and Replit. For privacy, Codenvy has a self-hosted option. 

Among the plugins are Live Share, Remote Collab, Atom Teletype, CodeTogether, GitLive and Floobits. CodeTogether supports VS Code, IntelliJ and Eclipse. Guests can join from IDE or browser. GitLive supports VS Code, IntelliJ and Android Studio. Floobits supports Emacs, Sublime Text, Neovim, IntelliJ and Atom. 


### How do I select the right tool for RPP?

Teletype for Atom suits pair programming's driver-navigator style. Live Share allows more open-ended collaboration, which perhaps is not what you want. However, Live Share might suit ping-pong style of pairing. In strong-style pairing, we want the navigator to guide the driver step by step. This is best done with only screensharing. 

In Linux, tmux and tmate are popular. These work even on low-bandwidth connections. However, this may not be the best choice for beginners who find it hard to learn the commands. 

Cloud IDEs may not be optimal for all-day coding. It's also too dependent on net connection. Plugins such as CodeTogether track changes within IDEs and are therefore not demanding on bandwidth (unlike screensharing). CodeTogether team also found that allowing multiple developers to edit code is hard to follow. Their design enforces a master controller who can give/take temporary control to others. 


### Could you share some tips for RPP?

RPP is easiest if the developers have met before in person. If not, have icebreakers at the start of the project. Informal chats or online games can also help in building rapport. Allow for frequent breaks since remote pairs get tired more easily. When remote pairing across time zones, select a time convenient for both. 

Start every session with a clear agenda. Tackle one task at a time. Some companies such as GitLab have an internal app to help developers pair up. 

Before pairing for long hours, get the basics right. Use a good headset that mitigates external noise and echo. Use a large monitor or even two monitors. Use comfortable desk and chair. 

Make use of non-verbal cues. Lean forward when you wish to speak. Gesture to draw attention. 

Frequently check with your partner about audio/video quality and quickly take corrective action. An audio splitter with two connected headsets allows another colleague to easily join in on any conversation. Always have the audio and video on, even during breaks. This gives the feeling of being connected to the "office vibe". 

## Milestones

1998

**Extreme Programming (XP)** as practiced at Chrysler is talked about. Pair programming is one of the core practices within XP. 

2001

In the *Agile Manifesto*, Beck et al. point out that face-to-face interactions are most effective. In this light, remote pairing is guaranteed to fail. This motivates research into adapting XP for distributed teams. Schümmer and Schümmer present *TUKAN* as a "synchronous distributed team programming environment". TUKAN includes chat, audio, multi-user code editing and integration with version management. They use the term **distributed pair programming**. 

2004

Hanks publishes results of an empirical study on RPP. He uses a screensharing application called Virtual Network Computing (VNC). He modifies VNC to support a second cursor that the navigator can use as a pointer. Unlike in earlier tools, the second cursor appears only when required. 

Jul  
2015

In a literature survey, da Silva Estácio and Prikladnicki find that most studies have been from a teaching perspective. Only a few studies talk about RPP in a real-world software development setting. They also survey RPP tools. They make recommendations about tool features: shared code repository, support for specific pairing roles, role switching, gesturing, etc. 

Oct  
2015

Tsompanoudi et al. modify a previously available Eclipse plugin and use it in an educational setting to help students learn programming collaboratively. Tasks are streamlined using **collaboration scripts** that were studied by other researchers as early as 2007. 

Jan  
2019

**Tuple** launches alpha release. It claims to be the "best pair programming tool on macOS". The focus of Tuple is performance: low CPU usage, low latency, high resolution video and no distracting UI components (sometimes called UI chrome). It also exposes performance graphs to the user so that they can take corrective action. 

2020

The COVID-19 pandemic forces teams to work remotely. Teams used to pair programming are now required to do the same remotely. The situation forces teams to better understand the dynamics of pairing remotely.  It's also expected that the arrival of 5G will make RPP more reliable and sophisticated. 

Mar  
2021

Packt Publishing Limited publishes Bolboacă's book titled *Practical Remote Pair Programming*.