Pairing

What is pairing?
Pairing means two people work on every task. Ideally this happens with the two people sitting next to each other looking at one computer screen, however adaptations are possible for pairs in different locations. The main point is that no stage of the work should have only one set of eyes on it.

Why pair?
Pairing improves software quality in a variety of ways.


 * A second set of eyes can catch bugs earlier, or make debugging easier
 * One person can act as the other’s conscience, reminding them to follow good programming practices
 * While one person is getting their hands dirty in the code, the other can think strategically

Pairing also helps share knowledge around the team, reducing individual code ownership (a bad thing) and helping new contributors come up to speed and learn good practices.

For most people, pairing also increases motivation and is more enjoyable than working alone.

Impediments to pairing

 * Distance: if your partner is not near you, you’ll have to find a way to pair over a distance. There are various technological solutions available (see below).
 * Timezones and schedules: in a volunteer project with people all round the world, it can be hard to pair with someone who isn’t available at the same times as you. If you can’t find a mutually agreeable time, you might need to fall back to asynchronous pairing.
 * Social awkwardness: pairing does require a certain amount of interpersonal skills, and can be challenging at first. Actually, most people find pairing difficult at first, but it’s a skill that can be learned, just like coding.
 * Overcommitment: if you’ve taken on (or been assigned) more work than you can finish in an iteration, it can be tempting to rush, and to work independently without your partner present. If this happens, please talk to the coaches for the current iteration. It’s better to cut down the task into something smaller, or put it off til later, than to break pairing discipline.

Pairing styles
The following are listed in order of preference. Please choose the first item from the list that you are both able to do.


 * Physically present at the same time, one computer. Two people sit next to each other and look at the one screen. If you have the gear, you can project the screen onto the wall to make it easier to see.
 * Physically present at the same time, two computers. Using any of the long-distance pairing mechanisms below, you can each look at your own screen and see what the other sees.
 * Long distance, shared screen and voice. Using one of the screen sharing mechanisms below and Skype or similar voice chat.
 * Long distance, shared screen and video chat. Using one of the screen sharing mechanisms below and video chat. It can be hard to arrange your desktop to fit the video and your work in the space, but the video doesn’t need to be very large to work.
 * Long distance, shared screen and IRC/IM. As above, only with a chat program rather than voice. You will need to work more slowly and be careful to talk about each step and reach agreement before it happens.
 * Long distance, no screen sharing, with IRC/IM. For instance if you're just fixing something small, you could discuss on IRC, do it, push the commit, show the person, discuss again, and repeat a couple of times if necessary.  Not suitable for large amounts of work, but may be ok for small changes.
 * Long distance, asynchronous. If you can’t match schedules at all, it may be possible to do the work and keep each other informed via email, code commits, etc. It’s important to work slowly and carefully in this case, making sure each step is reviewed and discussed in detail.

Pairing tips and techniques

 * Narrate your work. As you do something, talk about what it is you’re doing. For instance: “I’m going to add some unit tests now. First I’ll test the input to the function…” (and then you would type the relevant code) “… and now I’m going to check that it fails, because I haven’t written the code yet.” (you do so) “Right. Now I’ll actually write the function to accept the input.” And so on.
 * Take turns “driving”. One person drives for a while, and the other sits in the “passenger seat”, watching and/or offering comment. At some point the passenger will probably get frustrated and want to drive. You can just say, “Hey, can I drive for a bit?” The driver will pull over as soon as is safe and you swap seats. So to speak.
 * Pilot/Copilot – this supposedly comes from the way fighter pilots operate. The pilot, in the front seat, is responsible for tactical movement. The co-pilot, in the back seat, thinks more strategically and is planning ahead, and passes strategic suggestions to the pilot.  This can be a good way to share responsibility and keep both people involved all the time, rather than one just dozing off while the other codes.

Screen sharing

 * tmux - if you are on a Linux machine with full Internet access (such as our Hosted hack environment), you can both ssh into the machine and then one person can share their tty with another. This works best for people who are comfortable on the command line and with Unix text editors (vim, etc.)
 * TeamViewer - multi-OS (Windows/OSX/Linux/iOS) option for screensharing (free-as-in-beer for personal use)
 * various VNC options (many are open alternatives)
 * Bigbluebutton - Mac, Unix and PC requires server installation
 * Jitsi - Secure video calls, conferencing, chat, desktop sharing, file transfer, support for your favorite OS, and IM network. All this, and more, in Jitsi - the most complete and advanced open source communicator.
 * OpenMeetings - Openmeetings provides video conferencing, instant messaging, white board, collaborative document editing and other groupware tools using API functions of the Red5 Streaming Server for Remoting and Streaming.
 * Skype allows screen-sharing in video chats: hover the mouse over the video window until the "+" button appears, then click the "+" and select "share screens" from the menu that appears.

Logging

 * script – for sysadmin tasks or other things with a lot of command line work, especially if you and your partner are working asynchronously. You can turn on script and log everything you do, then save it as a text file to share with your partner.

Video chat

 * Skype
 * Google+ Hangouts

Open alternatives

 * Bigbluebutton
 * Jitsi - Secure video calls, conferencing, chat, desktop sharing, file transfer, support for your favorite OS, and IM network. All this, and more, in Jitsi - the most complete and advanced open source communicator.
 * OpenMeetings - Openmeetings provides video conferencing, instant messaging, white board, collaborative document editing and other groupware tools using API functions of the Red5 Streaming Server for Remoting and Streaming.

Voice chat

 * Skype
 * Telephone (if you are in the same area/have a phone plan that makes it cheap enough)
 * Mumble is open source audio conferencing - mumble website  RBOSE mumble page

Open alternatives

 * Bigbluebutton
 * Jitsi
 * OpenMeetings

Choosing a development environment
Different people have different preferences for development environment. The most obvious part of this is which editor you use to edit code. Who gets to choose which text editor to use, if each partner prefers a different one?

One option is that the “driver” chooses, but this can create an impediment to switching drivers, because it means switching dev environments each time you want to switch driver. However, it is possible, especially if your pairing style tends toward not switching often.

Another option is that the least experienced person chooses. That is, if you have an advanced coder and a newbie coder, the pair will use the newbie coder’s dev environment. This means that the new person can learn more about the code, and not have to spend their energy on trying to understand the text editor as well. Of course, an absolute beginner may not have a firmly established preference, so in that case you should try and settle on something which is at least easy enough for the beginner to understand.