Pair programming is a technique where two programmers work at a single work station.  One person “drives” or has control of the mouse and keyboard.  The other person “navigates” or keeps track of where they are and where they are headed.  This is a perfect environment for teaching and learning to occur.

Roles

Navigator

• Keeps track of the big picture.
• Responsible for directing the flow of work to a specific conclusion.
• Reviews code.
• Keeps track of tasks identified by the driver so they can focus on coding.
• Ensures that best practices are followed.
• Track potential code improvements.
• Asks questions about the driver’s implementation

Driver

• Implements the next task provided by the navigator.
• Gives future tasks to the navigator to track.
• Answers navigators questions.

Typical Pitfalls

Navigator

• Taking control of the mouse and/or keyboard.  Resist the urge to always be in control.
• Dictating every step of implementation.  Your partner is not a voice activated typing machine.
• Interrupting you partner’s thought process.  Write down your thoughts and bring them up when your partner is ready to focus on what you are saying.  Be patient.  Use this extra time to focus on their code and where your pair is headed.  You are supposed to be focused on the big picture.
• Failing to pay attention to what your partner is doing.
• Questioning every choice they make.  Trust your partner.  You can certainly question some of their decisions, but don’t question everything they do.

Driver

• Ignoring your partner.  The navigator is there to keep you on track.  Listen to them.
• Failing to explain what you are trying to accomplish.  Your partner is not a mind reader.  Before you start the next step take a moment to explain what you are going to do to your partner.
• Driving all the time.  This is not smart in a car and this is not a good idea when you are pairing.  Give up the keyboard periodically.

Rotating

Pair Rotation

Teams should agree on how often they will switch pairs.  I prefer to switch partners once a day.  This allows each team member to be exposed to different levels of expertise and different perspectives.  This also prevent teams from having knowledge silos.  On the other hand, switching too often can result in team members knowing a little of everything without understanding anything very well.  Take time to reflect on the effects of pairing on your team.  Adjust the practice of pairing to support the goals of your team.

Role Rotation

The driver and navigator should switch roles periodically.  Driving or navigating too long can become monotonous and mentally overwhelming.  My favorite rotation approach uses TDD as a cadence.

1. writes a failing test.
2. switch
3. make it pass
4. refactor the code
5. write a failing test (step 1)
6. switch (step 2)

This is just a rhythm that I enjoy following. It is fast paced and keeps my attention.  Try different thing and figure out what works best for you.  Just remember that each partner is different.  Find a pace that works for both of you.

Environment

• Make sure you have enough space.  Move you monitors to the center of the desk.
• Use comfortable chairs.
• Agree to take periodic breaks.
• Remove Distractions
  • Turn off or at least silence your phone(s).
  • Tell your significant others to not call/text during pairing hours
  • Suppress distracting new message signals for email
  • Ask other team members to not interrupt you during pairing time.
  • Try to avoid scheduling meetings during this time.  Block out time on your calendar.
• Keep some gum/breath mints handy to mask the onions you ate for lunch
• Get some caffeine in you before you start if you need some.
• Clean off your desk.  Make it inviting for your pair.
• Keep some scratch paper and pens/pencils available for notes.

Conclusion

I spent several years pairing 6 hours a day.  I learned more about people and software development than I have ever though I could.  I am not recommending that you try to institute a similar policy on your development team.  In fact, I was telling Extreme programmer Uncle Bob that our development shop required developers to pair 6 hours a day.  He was shocked and a bit appalled that we would require this much pairing.  He explained that pairing is a tool that should be used to distribute knowledge throughout our team.  He recommended that we consider being less extreme in the area of pairing.

When we first instituted this requirement we found that we were more tired than usual, at the end of the day.  Many of our spouses began to notice that we did not talk as much in the evenings.  This fatigue stemmed from the focusing nature of pairing.  We were learning and thinking more than we had before we started pairing.  Pairing is a valuable tool that should not be ignored or abused, but rather used to improve your team.

Time and time again, I have uncovered issues that have been ignored and/or hidden by exploring “over reactions”.  They are indicators that there is more to the story.  For example, one of teams that I was leading was very frustrated with how much time we were spending estimating stories.  Their frustration eventually culminated in some of the team members refusing to participate in team estimation meetings.  As you can imagine this created significant tension between the developers and the business team.

While some teams do take too long to estimate, this team generally spent less than 1 percent of their month estimating cards.  With this unequal and opposite reaction focusing my attention I began to interview team members one-on-one.  These conversations confirmed that there was a problem, but failed to adequately explain why.

At this point I approached the Project Lead and requested that we all sit down and discuss the estimation process.  At the conclusion of this meeting two things were clear.  First, the development team did not trust the business team’s motivations for gathering estimates.  Second, they did not feel like decision makers were adjusting their expectations based on the estimates that they received.

This conversation helped both sides understand each other.  While this was not a magical cure, it did realign the action of estimating and the team’s reactions.  This may still seem like it was not worth addressing.

On the contrary, exaggerated emotional investment can be a significant source of waste.  This type of waste is often expressed through frustrations, confusion, fear, and/or apathy.  Individual opinions spread throughout teams and become a significant source of waste.  The only way to reduce this waste is to understand the root causes.  I do not have a perfect approach to efficiently identify these sources.  In my experience it takes patience and persistence to uncover the truth.

These principles also apply to under reactions.  Some teams that have lost hope will withdraw.  The under reactions that will follow are just as important to address as over reactions.  Remember to pay attention to wheels that are abnormally quiet while you are oiling squeaky wheels.

As technical people we often shy away from feelings, however like it or not our teams are made up of people.  People that have feelings that are formed by their experiences and perceptions.  Ultimately people want to be heard and understood.  Once this occurs, teams tend to realign their reactions.

I’m currently working an Agile project with three developers including myself. We’ve divied up the tasks so that one is doing the JSF database plumbing, and the other two are creating the web services that sit on the back end. We started development without having a certain idea of certain database keys, so we naturally wrapped the keys in an object that we could easily change when the decision was made. It let us move forward with development and had a very low cost for change when business came back with a decision. But we each implemented it in a difference way, using a different nomenclature and at different times. So now we have three objects that perform identical tasks, and require a translation process when our respective parts interact with each other. It’s not broken, but it’s definitely messy.

And it’s a natural fallout of the tendency to think that Agile means you start developing right away, and things like requirements and interfaces can be laid on top of the code later. How do we prevent it? Sadly, communication is the only answer. Code reviews early on could have prevented this situation before it would have been a pain in the tuckus to refactor. A project wiki exists, and even has a section that lays out common objects and interfaces. But the wiki was infrequently referenced for matters of actual code implementation; it was for the documents and the Agile storyboards.

In the end, it’s important to recognize that Agile development has taken the large chunk of communication out of the beginning phase of a project. But that communication isn’t gone, it’s been spread out over the duration of the project, and in most cases that means there going to be a lot more of it. As developers we eagerly embrace Agile projects since it means we don’t spend two months in design meetings and can’t indulge our love of code early on, but we have to realize that it comes with a cost. We actually have to talk to each other.