I Won’t Like Pair Programming

There are two things behind this objection. First, it is uncomfortable for
developers to work with others. They've never done it before. Programming is
perceived as a lone wolf activity; XP says you should hunt in packs. Second,
whether they want to admit it or not, developers aren't particularly fond of giving up
their place in the sun. With no code ownership, they believe it is harder to be the
hero. This is the developer pride problem rearing its ugly head.
The way to handle this objection is to focus on the benefits of pair
programming. Emphasize the knowledge sharing, the improved code quality, the
increased morale. Then suggest an experiment where you do all programming in
pairs for a couple weeks. At the end of the experiment, you can decide as a group
when it makes sense not to pair. We've found that programmers start to like pairing,
and see the benefits, after about the first week. They will start to communicate better
and to feel more human. During the second week, they normally start to hit their
stride.
In a study Laurie Williams conducted, she found that 90% of people who tried
pair programming liked it. Our guess is that some of the other 10% could be won
over with a little more sensitivity to identifying what it was about the experience
they didn't like and making some adjustments before a second attempt is made.
When the trial period is over, ask them what parts of pair programming they are
still struggling with. After they have shared, give them a simple choice. You can
work through those issues as a team, or they can "give up." Be sure to put it this
way. It is both truthful and motivational. Developers hate to quit on a problem.
You might face a "green eggs and ham" team. They might refuse to try pairing
because they are sure will hate it. If no one on the team is willing to try pairing,
you've got two choices. You might determine that you work with people who are
afraid of trying anything new and decide how long you want to stay in this
environment. Or, if you have some sort of authority, you might find a creative way
to force them to try it. For example, decree that the most critical portions of the
system must be developed in pairs. This will make pairing more attractive. State that
hate being subject to those, and they hate doing them even though it has proven to be
a huge contributor to software quality1.
There have been several studies that show Code Reviews are the biggest
contributor to software quality. Even above testing. This is amazing considering
how poorly we execute Code Reviews. A bunch of people who haven't struggled
with the problem get to pick apart those that have. Certainly we are supposed to
provide only constructive criticism, but it is very difficult for the person having their
code reviewed to not be on the defensive and it is difficult for the "gurus" in the
room to not find something to pick on (to establish that they are smarter than
everyone else).
One study showed that 90% of the benefit of a code review was attained by the
first person reviewing the code. We think this is due to two main reasons: 1) before
you present your code for review, you conscientiously clean it up so you don't look
bad, and 2) most of the things you missed because you were so engrossed in the
problem you were trying to solve, any other competent developer would see as soon
as they looked at it with a fresh, critical eye.
Among other things, pair programming get you these benefits in a less
intimidating and more productive way. You don't have to do as much "code
cleanup" because you are always conscious that your work is being viewed by
someone else. You don't have to be as defensive, because the constructive criticisms
come a little at a time. When you just "hack something to see if it will work" you
can communicate that this is what you are doing to your pair. Your pair will then
remind you that you have to go back and clean it up. And, of course you both get to
learn from each other and have discussions about the value of certain approaches as
peers rather than as someone who is being interrogated.
Pairing is critical to success. It also is a healthier way to develop software. This
is a case where you might have to practice a little tough love. It is for your
developers' own good.