Topics

• What is pair programming?
• Why Pair Program?
• How Pairs Form
• When to Change Partners
• Can't I work alone?
• Doesn't this cut my productivity in half?
• Hygiene and Etiquette Issues
• Disabilities and Physical Incompatibilities
• Our Team is Geographically Distributed
• My Pair Partner Hogs the Keyboard and Ignores Me
• My Pair Partner and I Cannot Agree on a Solution
• My Partner and I have different First Languages
• How do we deal with different personal schedules?
• What if we have an odd number of programmers?
• Pairing Pathologies

What is pair programming?

Pair programming is a programming discipline in which all production code is written by pairs of programmers. Each pair works together at a single workstation. They share the keyboard, mouse, and monitor.

The two programmers work closely together. The keyboard moves back and forth between them frequently. Both eyes are locked on the screen. Both minds are immersed in the code. The code is the product of both brains, not just one. Both programmers are equally engaged in writing the code, and neither can claim authorship.

Pairs are short lived. A good pairing time is four hours. Sometimes a pair may last for a day. Very rarely they might last for a week. Instead, the pairs form for a few hours and then break up and reform with different partners.

During the iteration-planning meeting, each programmer signed up for tasks to complete by the end of the iteration. The programmer remains responsible for those tasks. Half of the pairs he works in will be working on his tasks, and half will be working on other's tasks.

Why Pair Program?

Pair programming is a form of continuous code review and usually replaces the practice of code reviews and code walkthroughs. The idea is that if code reviews are a good thing, then continuously reviewing the code is better.

Even though every task is the responsibility of an individual programmer, many other programmers will have worked on that task with the responsible programmer. Thus, knowledge of the system spreads through the team, and no single programmer can claim ownership of any part of the code. It is likely that any programmer on the team will be able to work in any module in the system.

Sometimes you get stuck on ideas and can't see past them. Your pair partner can often provide the necessary nudge to get you to see a different point of view.

When new people join the team, they learn by pairing. Over the course of one iteration, they will pair with everybody on the team and see every part of the system currently being worked upon. This is an excellent way to train a new team member.

How Pairs Form

You come to work in the morning and attend the stand-up meeting. Then you walk up to someone and ask him if he'll help you. Or perhaps someone will walk up to you and ask you to help him. The rule is: when asked, you must say yes. However, you can negotiate schedule.

Pairs form naturally. Managers do not get involved with selecting pairs. Pairing is not scheduled or controlled in any formal manner. The coach or another team member or the team as a whole may notice that certain team members have adopted pathological pairing activities and may intervene.

When to Change Partners

• When you get tired of your current partner.
• When you think your current partner is too tired or distracted to help.
• When the two of you get stuck on a concept.
• Lunchtime.
• Quitting time.
• Or generally whenever you feel like it.

Can't I work alone?

Yes, of course. You just can't check in production code that you've written on your own.

Often we need to hide away somewhere and think some issue through without someone else breathing down our neck or distracting us with news of his sister-in-law's hypoglycemia. It is perfectly OK to hide away, and every programmer should have a private place to go.

When alone, it is perfectly OK to write some code to help you think through a program. However, in an XP team, you are not allowed to check that code into the production environment. Instead, you can bring that code to your next pairing session and walk through it with your partner. Your partner must be given every right to modify, delete, or otherwise refactor it. You should help your partner become comfortable with the code and keep an open mind to every refactoring.

Often the best approach is for the two of you to review the code you wrote and then rewrite it as a pair. Remember, the value of a piece of code is not actually in that code. Rather, it is in the neurons and synapses of the programmers. It is always much easier to write a module the second time, and the result is always better. So, if you program alone, think of the code as a rough draft that you will throw away and rewrite with your pair partner.

Doesn't this cut my productivity in half?

Apparently not. Teams that work in pairs do not report significant loss of productivity. Indeed, they tend to report that they are more productive than when they worked alone.

This anecdotal evidence is backed up by some research studies. Some of those studies can be found at www.pairprogramming.com.

One might explain these results by viewing the programmers as two runners pacing each other. When one gets tired or defocused, the other provides the motivation and inspiration to keep going. Also, the pair spends less time going down dead ends and being blocked on ideas.

One thing seems clear. Typing is not the critical element. If it were, then pairing would certainly cut productivity in half. It may be that pairing allows the two to think twice as quickly.

Hygiene and Etiquette Issues

Hygiene and etiquette issues are bad breath, body odor, post-nasal drip, colds, rude noises, gas, motor mouths, telephone-jockeys, day-traders, hypochondriacs, etc. Humans are a dirty species. Amazingly, we are usually able to get along with each other's nasty little idiosyncrasies, but there are times when one person has certain habits that are over the top. How do you pair with such a person?

• Grin and bear it, it'll only last for a couple of hours.
• Bring breath mints.
• Leave deodorant or gelucel on his desk.
• Write anonymous letters to the offender.
• Disconnect the phone.
• Complain to your boss.
• But, by far, the best advice is to tell your pair partner outright what bothers you.

Disabilities and Physical Incompatibilities

• Left handed vs. right handed mouse users.
• Some people need special keyboards to control RSI or OOS.
• Some people use Dvorak keyboards.
• Some people need to special screens to be able to see.
• Some people prefer a trackball to a mouse.

Problems like these are pretty easy to overcome. Equip certain workstations with two keyboards, two mice, two monitors, etc. Pairs don't have to work at the exact same keyboard, mouse, or monitor.

In fact, pairs don't really have to use the same workstation. They could use two completely independent workstations sitting next to each other, connected with NetMeeting or some other kind of collaboration software.

Our Team is Geographically Distributed

At best, pairing over geographical boundaries is difficult. The best approach is to split the project up into sub-projects that can be done separately at each geographic location. That way the programmers at each location can pair with each other and won't have to interact as much with the remote programmers.

Sometimes the project cannot be easily split amongst all the geographic sites. In that case, you can use NetMeeting or other collaborative software to facilitate remote pairing. Remote pairing is possible but not as effective as local pairing. When you pair locally, you have the advantage of body language, eye contact, and all the other nuances of person-to-person communication to help you. When you pair remotely, you are forced to use a sub-optimal communication channel.

My Pair Partner Hogs the Keyboard and Ignores Me

• Perhaps you are outrunning him. Try to go a little slower and get him engaged.
• Perhaps he's got personal problems that are distracting him. Suggest that this might not be a good time to pair.
• Perhaps he thinks you aren't listening to his ideas. Make sure you talk though all ideas with him, and make sure he has a chance to try as many of his ideas as you get to try of yours.
• Perhaps he thinks you've been hogging the keyboard. Push the keyboard in his direction and ask him to drive.
• Perhaps he is just not ever going to want to pair program, no matter what. For the moment, the best you can do is dissolve the pair and choose another partner. If the behavior continues, the team will have to decide what to do about it. Perhaps the team will ask him to write configuration scripts or something.

My Pair Partner and I Cannot Agree on a Solution

• Gently ask him if you can drive for a while.
• Gently ask him to describe what he is doing.
• Perhaps he needs time to think alone. Suggest this to him and dissolve the pair.
• Perhaps he just can't pair program. Dissolve the pair and choose another partner. If the behavior continues, the team will have to figure out what to do.

My Partner and I have different First Languages

Your only choice is to slow down and work hard to communicate. You might understand him better by writing strategic notes than by talking. Work hard on helping him with pronunciation and grammar. Work hard at understanding his accent and usage. It will take time, but the situation will improve. Do not give up!

How do we deal with different personal schedules?

Some people come in early; some people stay late. How can you find pair partners if everybody has a different working schedule?

Pairs only last for a few hours. All you need is enough overlap time for pairs to form and work effectively. Most personal schedules allow this.

Team members may have to get creative with their scheduling to accommodate each other. Some folks may have to change their schedules to make sure that others have sufficient pairing opportunity. For example, if Bill can only work in the evenings, the team may decide to adopt a rotating schedule for others who can come in late one day and pair with Bill.

What if we have an odd number of programmers?

Remember that pairs break up and reform frequently. The odd man out will not have to wait long before someone becomes available to pair with. In the meantime, he can read his email or a trade journal or just read through some code that he is unfamiliar with.

Pairing Pathologies

• Joined at the hip. Sometimes two people decide to pair exclusively. This is not a good idea. They are missing the opportunity to get the whole team's input and are isolating themselves into one part of the system. The team should break them up by suggesting that they pair with others.
• The blind leading the blind. It's not a good idea for new members of the team to pair too often with other new members of the team. Newbies should pair most often with team members with more seniority.