Programming in Pairs

XPlorations

XP123 → XPlorations → Programming in Pairs (May 2000)

Programming in Pairs - Some Scenarios

May, 2000

Goal: Show and critique several episodes of pair programming.

A Few Short Examples

Solo

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". Steve Metsker of Capital One says, "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 he created.

Crowd

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.

Disengaged

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.

True Pairing

Don asks Lee to be his partner on the next task. Here's the card:

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 digits.

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 potential bug.

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, right."

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 to switch.

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:

|Mary and Bob Smith
Bob|D'Santos
_|John Smith
Socrates|
|Plato
Aristotle|A. Smith
|JOHN SMITH
|John Smith
John|Smith
|'()$#"@
|(none)
and so on.

You might see short or long names:

Wu|Wei
Archimides|Apollonniganymedea

and you might see some tough duplicates:

John|Roberstoniton (20 of these, followed by)
John|Robertsonitony

You'd have to be careful not to assign two "jrobertsoniton"s.

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 anything really."

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 over.

They agree on a new strategy: Use a Unix pipeline, first writing out id #, first, and last name:

shift the name to lower-case and delete anything not a letter
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
sort
build and write the names. If a name duplicates the previous one, append the counter.

They set up some test cases:
     1|John|Smith
     2|John|Smith
     3|Wu|Wei
     4||
     5|(504)|555-1234
etc.

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 break.

Analysis

This was a hard session, perhaps harder than typical. We saw many interactions typical of pairs, though:

Asking a partner for help (and receiving it)
The partner helps with both strategic and detailed thinking
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 them.

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.

Resources

Extreme Programming Explored, by Bill Wake. This article is the basis for chapter 4.

[Written 5-13-2000; fixed typo 6-5-2000.]