Pair Programming Duration

Q: How long does a PairProgramming episode last?

A: Pairs switch multiple times per day. (...with some exceptions, noted below.)

[Discussion moved from WorkQueue, to make it more visible.]

How does WorkQueue mesh with PairProgramming? With a CommitmentSchedule, I understood how pairs could switch off at team-wide completion events - how would they do it in this approach? -- RussellGold

Pairs switch multiple times per day. Once in a while people will work together on thing X for a few days in a row. Recall that we release code approximately daily for each task. After that task is done, and you're working on another, it's easy, and often quite appropriate, to switch partners. WorkQueue works just the same way. Pairing is more like grabbing the person best-qualified to help with this thing right here than picking a partner for weeks at a time. --RonJeffries

Now I think I am more confused, rather than less. I had thought that assignments were equal to user stories, and that a pair would grab one or more complete stories at a time (presumably only one in WorkQueue) and work together until their assignments were complete. What you are describing, though, sounds more like an individual takes on an assignment and looks for a helper for that assignment - presumably that helper has no assignment of his own or is putting it on hold to help the first person. Exactly how does this work? Do you roam around looking for someone to help you? If the right person is unavailable, do you work alone for a (potentially long) while? -- RussellGold

Yes, an individual takes on an assignment and looks for a partner. The partner of course also has an assignment of her own. Often, but not always, there is a quid pro quo: we'll work on yours, then we'll work on mine.

There isn't any "right" person to help you. Anyone can help anyone. One of our rules is that when someone asks for help, you can't say no unless you are already helping someone.

You can work alone, but you can't do production code. There are plenty of other things you might do. If you work on your task, that's OK. The best thing to do next is to remove all the code, now that you know how to do it, and grab a partner and put it back in. A far second best is to bring in a partner and sit them down and bring them up to speed on what you have done.

Also recall that stories are broken down into engineering tasks, and it is those that are signed up for. Different partners for different tasks is quite common. -- RonJeffries

So that the DoIt staff would learn how to pair program, we allow very little code (production or maybe-production) to be written without a partner. Based on Ron's options above, we might consider relaxing the rule now that continual pair programming is the default mode. I would worry about falling back onto old habits, though. The temptation is very great, and then we spend time catching up on code changes. Or worse, code changes go unexamined until a problem surfaces.

The only visible defect in DocumentCentral was introduced during one of the few solo programming episodes. -- JamesCollins

[CategoryPairProgramming]