Skip to content

The challenges of pairing in software development

April 9, 2011

Pairing is a big subject in software development teams that use XP, Scrum, or the like. In almost all cases, pairing refer to developer pairings, but it can also be applied to QA pairings, BA pairings, or mixed-role pairings.

Since pairing is a big subject and a common practice in XP teams, why do issues/concerns often come up about pairing? We talk about it in dev huddles, we mention it in retrospectives, some of us avoid it, and some are tired of it at the end of the day.
Why? What are the problems?

  1. One thinks there is no value in pairing. “This is a simple work. I know what to do.”
  2. One wants to have freedom in writing code the way he/she wants it to be. Nobody would say “Hey you know, this code is too complicated. How about …”
  3. One worries that he/she will get slower in finishing the work. Nobody would say “Why do you do it this way? What does that mean?”
  4. One worries that he/she can not catch up with the speed of his/her pair. “I wish I had more time to look into that class and figure out what it does.”
  5. One does not like the attitudes of this/that team member(s).

I have noticed that even when some people are experienced in XP and understand the value of pairing, they can still be reluctant to call out that they need a pair. They are intentionally passive in finding and switching pairs. They  think, “If nobody asks to pair with me, I’ll work on my own.”

Then there is the other side of the group where people simply do not get the value of pairing. Regardless of what people think, by avoiding pairing, they hurt the team if not themselves. I would actually argue that they hurt themselves, in later points.

Now, let’s talk about each one of those common thoughts.

Challenge #1: There is no value in pairing

How many times have you been in a situation where you were asking someone a question and all of a sudden you hit the idea, “Oh, hold on, it works like this, right, .. ah I figure it out!” Just talking it out to someone or reciting my plan of work out loud helps direct my train of thought.

How many times have you were confident of a solution and wrote the code until almost done, before you found out, “No, this doesn’t work. I didn’t realize this class was intended for that purpose. I thought I could fit in the new business logic easily in here.” When I pair, my pair is my second set of eyes who think about the bigger picture while I am busy translating my thought into the code. My pair would say, “Hold on, what if …” “Let’s think through this again.”

Lesson #1: My pair helps me to slow down and think of a solution more thoroughly, and to figure out a problem together.

Challenge #2: One wants to have freedom in writing code the way he/she wants it to be.

There are many project teams in different companies that have a phase called “code review”. Sometimes the team sets up a meeting where everyone goes through the code changes for a particular feature. Sometimes the developer(s) sends out review invites to several team members to go through their code changes.

Regardless of the variations, at some point during the development phase, team members often have to look at other team members’ code, evaluate them, and give feedback. With pairing, we just make the code evaluation and feedback instant. One person focuses on implementing the logic, the pair can be watchful for unnecessarily complicated code, ambiguous method names, or other code smells.

In an ideal situation, the pairs switch on a frequent and regular basis, such that more than two people will have looked at the code for a particular story/feature. This essentially reaches the same goal as the code reviews. There is even an extra advantage with the time:  shorter feedback time means quicker code changes and better code quality overall. There are less time periods where the code is buggy or incomplete until the issues are found out during a code review.

Lesson #2: My pair helps to evaluate my code and give me instant feedback to improve the code quality during the story development.

Challenge #3:  One worries that he/she will get slower in finishing the work.

On one side, I want to finish the task as soon as possible. I do not want to get dragged down by my pair, who is a new team member, by going through every little detail in the code. I do not want to have to explain every concept while changing the code. On the other side, I also want this new team member to ramp up fast and to understand a problem or solution faster in the future.

How do I achieve this? Well, I have to be open to mentoring this new team member and sacrifice some time in the beginning, in the hope that she will do better and better in the next tasks. Yes, I will go slower now, but in the long run, the team will be more solid. Or are you ready to sacrifice long-term team capability for short-term gains?

I also find that when I explain my train of thought out loud, I am more aware of the details that I miss, things that I do not understand yet myself, and of the great questions they ask! I also find that different people may look at the same problem in different angles and that helps point out potential issues with the solution at hand. That, once again, leads to better code quality.

Lesson #3: Be open to sacrifice development time in the beginning, to help other team members catch up and be solid in the future.

Challenge #4: One worries that he/she can not catch up with the speed of his/her pair.

Well, you are right. If you pair with a more senior developer, either technically or in terms of project experience, you may not follow everything in the beginning of your time at the project. Everyone has to learn to walk, sometimes with parents holding them, sometimes without anyone around. When you pair, make sure to ask questions and be ready to have some answered, and some to be researched at your own time. Don’t worry, your questions will only make you a better team member.

If you show enough initiative and interest in the problem at hand, your pair may even help you to be a technology/domain expert in that area.

Lesson #4: Learn to crawl, then to walk, then to run! We will clap on you.

Challenge #5: One does not like the attitudes of this/that team member(s).

I have to be honest. In my first few pairing times, I was yelled at and treated like I did not know anything and I needed to follow my pair submissively. I had been accused of writing bad code. I had been asked when I graduated college, in what area, and how long I had worked in the industry. Say goodbye to friendly team members and supportive environment. I felt threatened and looked down upon. I know not to do these to anybody. If someone does that to me, I should give them the feedback.

There are other cases that are not related to junior-senior team members relationships. I dislike pairing with someone who is often absent without proper reasons. I dislike pairing with someone who controls the keyboard all the time. The key to this is not to avoid pairing, but to give my pair the appropriate feedback. Giving feedback is another difficult task by itself, so I will not talk about it here, but that is the way to go.

Lesson #5:  Step up and remind someone that his/her behavior is counter-productive to pairing and is uncomfortable to you (and potentially to other team members, too).

See, there are explanations to all these challenges and better ways to handle them than to just give up pairing. We all need to learn to be patient and open to one another’s views for the betterment of the team and of ourselves.

No comments yet

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: