Page 100 -

on it should be people who have done similar projects in the past. These circumstances
can provide an opportunity for an easy win, which in turn will increase the programmers’
confidence in the technique.
Some teams have found that pair programming works best for them if the pairs are con-
stantly rotated; this helps diffuse the shared knowledge throughout the organization. Any
two programmers can potentially make a well-functioning pair, no matter what their rela-
tive experience. Some people have found that it helps to choose pairs that include both a
senior person and a junior person. This will make it easier for the communication to fit
into an existing pattern (mentor and tutor, roles that both people are already used to—
although this is not necessarily how all senior-junior pairs will interact). Often, a junior
team member will ask a seemingly “naïve” question about the code that turns out to iden-
tify a serious problem. This is especially common with problems that the senior member
has been living with for so long that she no longer notices them. Sometimes, the extent of
a code problem only becomes clear when it is explained to somebody else.
Pair programming is not for everyone. It is difficult to implement pair programming in an
organization where the programmers do not share the same 9-to-5 (or 10-to-6) work
schedule. Some people do not work well in pairs, and some pairs do not work well
together. The project manager should not try to force pair programming on the team; it
helps to introduce the change slowly, and where it will meet the least resistance. Some
programmers will argue that assigning two people to one task is a waste of time, claiming
that two people can get twice as much work done if they work separately. While this may
seem true at first glance, the pair will introduce far fewer defects; it may require more
man-hours to do the programming, but it will reduce the amount of time spent on bug-
fixing and maintenance. However, this may not convince some stubborn programmers. In
this case, an effective way to introduce this technique is to begin with the people who are
more excited about the idea. Their success can help to convince the stragglers of the value
of pair programming.

NOTE
More information on pair programming can be found in Extreme Pro-
gramming Explained by Kent Beck (Addison Wesley, 1999).

Use Inspections to Manage Commitments
A successful project needs more than just a blanket agreement between team members.
It’s very easy for someone to “agree” to a document, only to turn around later and decide
that he didn’t fully understand what he was agreeing to. Instead, the project team needs
to reach a true consensus, where each person fully supports the document. The goal of an
inspection is to build consensus on the document by gaining a real commitment from
everyone who has read it. When a reviewer approves a document, he takes responsibility
for its contents, and if the document has defects, he shares some of the blame for missing
the mistake.

92 CHAPTER FIVE