|Programming in Pairs - Some Scenarios
|Goal: Show and critique several episodes
of pair programming.
A Few Short Examples
Bob is feeling great - he came in at 6:30 AM today. He picks up the
next task card, does a quick design, and starts writing tests and
code. In a couple hours, he integrates his code to the main system,
and all tests pass on the first try, just as the rest of the team
shows up for work that day.
Bob may be a great programmer, but as you might expect, this is
not an example of pair programming. Even a team that's fully
committed to pairing will occasionally face the temptation to skip
it "just this once". The late Steve Metsker said, "If it doesn't
pinch sometimes, it's not a real methodology."
Solo programming can cause several problems. In the example, Bob
may not be having as good a day as he thought - he may be passing
tests, but not refactoring enough. The design may work but not be
as simple as it could be. Also, we've avoided some potential
cross-team learning - Bob is the only person familiar with the code
Janna picks her task card and asks Jay for help. Jay says, "Hey
everybody - we're hooking up the joystick to the spaceship - come
see!" The whole team (all 10) crowd around to watch and make
suggestions. In an hour (or so), everything is working. Everybody
takes a turn, and they all agree it's pretty cool.
Again, this may be good programming (and it may be fun) but it's
not pair programming. The code may be fine, but it cost 5 times as
much as it should have, and other work was delayed meanwhile. This
is not to say that all pairs and all partners will always be able
to handle all problems, but it ought to be rare to require the
whole team for an extended time. The "celebration" at the end may
be fine - a team needs to recognize its successes - but let's
recognize it as non-producing time.
Pat asks Ann to be her partner for the morning. Pat starts in, but
Ann just sits behind her, arms and legs folded, physically present
but not paying any attention. Her attitude projects, "You can make
me sit here, but you can't make me help."
It takes more than physical presence to be a partner - it takes
engagement in the task. In this case, if Ann is consistently a
problem partner, the team will need to work to bring Ann into
alignment with the team's practices.
|Don asks Lee to be his partner on the next task. Here's the
|Task: Assign Usernames
Assign a username to each person in the system. Usernames need to
be 6-14 characters long, and must start with a letter. If it hasn't
been take already, the username should be the first initial plus
full last name.
|Don and Lee talk to Carol, the customer, and find out a little
more. This is a one-shot update - new entries will come with a
username. Also, usernames should only have lower-case letters and
Don says, "Let's start with the simplest test case: ignore the
problem of duplicates, and generate 'bsmith' for 'bob smith'". He
starts to write code for the test, and says, "What are the
parameters to substring()?" While he does the mechanics of
the code, Lee looks up the method, and says, "It's one-based, like
this..." and explains.
Don is focused on the mechanics of coding, so Lee is free to
support the task at a higher level. Instead of making a guess about
the method, they've checked the real description, and avoided a
|Don says, "It gets harder when we have the second 'bob smith'.
We'll need to keep track of the names somehow - we can generate
them in order, I guess - an add a number field to put on the end.
Let's assume they call our routine with names in order. Let me add
a variable for lastBaseName, and then..." Lee interjects, "Wait -
we need to write the test first!" Bob blushes and says, "Oh,
The partner can help make sure team values aren't ignored.
|Don starts again, "Hey Carol - if you have two 'Bob Smith's do
you want the second one to be 'bsmith1' or 'bsmith2'?" Carol says,
"I guess 'bsmith2', unless it's a lot harder." Don finishes the
test. He makes a typo, but Lee holds off a second before pointing
it out, and sure enough he fixes it before she says anything..
We see the value of an onsite customer. Again, the partner has
focused on potential quality problems. Notice the holding back - if
Don had missed the typo, Lee would have spoken up, but she didn't
want to interrupt his flow unnecessarily.
|Don gets the code going and the test working. Lee says, "We
still need to cover the case of a name that's too short. Can I
drive?" Don passes the keyboard, and she creates a test for "ye
wu". After a quick consult with Carol, they decide this should be
"yewu01". Lee gets the code working, and Don says, "We also have to
worry about mixed case." Lee says, "Do you want to drive?"
The partner thinks strategically, making sure key cases aren't
omitted. Also notice the protocol for passing the keyboard - "Can I
drive?" With practice, pairs will develop a sense of knowing when
|Lee says, "We should refactor to make all this work together
cleanly." They move code around until it's clear and concise. Bob
then easily drops in the new feature.
Lee says, "I've been thinking - we really have three problems:
the real name, the username, and the mapping between them. The real
name could have many problems: case, length, and so on. Do we
understand all these problems? The username has its restrictions
too: length, case, and use of digits. Finally, we need to know the
mapping for each type of name. Let's sit with Carol again."
More strategic thinking, and learning as well. They've learned
more about the problem structure from what they've done so far.
|They snag Carol for a real sit-down. They have a good handle on
the requirements for the username, but names have a lot of
subtlety. Carol says, "I've been looking into it this morning, and
our data is actually pretty dirty. You might see any of these:
You might see short or long names:
- |Mary and Bob Smith
- _|John Smith
- Aristotle|A. Smith
- |JOHN SMITH
- |John Smith
- and so on.
and you might see some tough duplicates:
You'd have to be careful not to assign two "jrobertsoniton"s.
- John|Roberstoniton (20 of these, followed
The good news is: we're really not all that picky about what
names you assign. If people really hate them, they can call and
we'll change it."
Lee asks, "What's the worst case for number of duplicates?"
Carol says, "If you assume 99 or fewer, that's OK - except for one
crucial case - the dirty data with no alphabetic characters. There
are a lot of those. You can assign them something like 'x00001', or
This is not the best news, since they've already started, but
it's better to find out now than later.
|Don and Lee go back to their code. Don says, "This looks pretty
far down the wrong track - should we toss it?" Lee says, "Yup -
it's the right thing to do."
The partner gives you permission to do what's needed. Sometimes,
that's tossing code while retaining the learning, and starting
|They agree on a new strategy: Use a Unix pipeline, first
writing out id #, first, and last name:
They set up some test cases:
- shift the name to lower-case and delete anything not a
- use an 'x' for the first and last name if they're empty
- trim to at most 12 characters
- add enough 0's to make it at least 6 characters
- build and write the names. If a name duplicates the previous
one, append the counter.
Don: "What if we still get a collision?" Lee: "We'll just
report an error, and do those few by hand."
They write their pipeline, trading back and forth as before.
Once the tests run and they integrate, they take a well-deserved
This was a hard session, perhaps harder than typical. We saw many
interactions typical of pairs, though:
Pairing is a skill - it takes practice, and it doesn't start out
easy for everybody. Pair programming is a crucial skill in XP, so
it's worth cultivating the habit to take advantage of the benefits.
- Asking a partner for help (and receiving it)
- The partner helps with both strategic and detailed
- There's a protocol for changing hands: "Can I drive?"
- The partner provides an ongoing quality boost: review,
refactoring, unit testing, new ideas.
- The partner provides permission to do the right thing, even if
it's starting over.
- If one partner forgets something, the other can remind
[Written 5-13-2000; fixed typo 6-5-2000.]