PairProgramming

I want to reopen this old thread with a new question. Leave the old stuff under the double line, and pick up the thread here a the top. - JerryWeinberg 2005.03.23

Question: If pair programming is so good (and I think it is), why isn't triplet programming better? Or is it? Or maybe under some circcumstances 1, 2, 3, or N is the best number. If so, what circumstances?

Start here:

I haven't done more-than-a-pair programming, but check out:

http://www.agilealliance.org/articles/articles/MobProgramming.pdf

KeithRay 2005.03.24

Part of it is how to make space for everyone to talk with each other. Imagine me pairing with two introverts. I shudder. -- JohannaRothman 2005.03.26

Johanna Rothman writes Imagine me pairing with two introverts. I shudder.

What if you were paired with Jerry Weinberg and Dave Smith? I doubt whether you would have that objection. The vital choice revolves around which people, regardless of whether they are introverts or extraverts, that you can work with effectively and who can work with you effectively.

I suspect that you might work poorly with many extraverts. Introversion or extraversion are only a single dimension and each is merely a preference. The whole of a person is greater, and more important, than a single dimension of type.

Isn't your spouse, Mark, an introvert? Do you "shudder" to pair with him? I'm laughing out loud because I know the answer.

I'll bet that you could design an interview that would help you determine who would work and who wouldn't.

SteveSmith 2005.03.26

Hmmm. I think maybe (in some circumstances, disclaim disclaim disclaim) more than 2 doesn't work because one person can be at a different level of engagement than the others. In a pair, both members are generally at the same level of engagement with each other. In a triad, two people can be deeply engaged, and one not-so-engaged.

I experienced this when three of us were brainstorming features for a product backlog. Two of us started really getting in to it (deep engagement), and the third person turned around and started reading email.

--DaveLiebreich 2005.03.26

Steve, I love the idea of working in a triad with Dave and JR. And I think we'd be great, greater than any two of us (who would still be great, too). I think that's (partly) because we have great respect for one another, some fairly good understanding of what it takes for people to work together, and (yes, even for JR) the ability to listen.

Dave, I think your triad must have been missing at least one of these elements. And you might be missing the one greatest advantage of a triad (which can also be its greatest weakness): In a triad, for the first time, you can have a member observing interactions between people. Perhaps your third party reading email was his/her (admittedly unskilled) method of telling you that something wasn't quite right about the interaction of the other two of you. - JerryWeinberg 2005.03.26

Actually, Mark is an extrovert, but compared to me, he looks like an introvert :-) I really like the idea of designing an interview to see how well people could work in pairs, triads, etc.

And I agree with Jerry that working in a triad with Dave and Jerry would be a blast. Since I've been practicing pairing with Esther, I'm more attuned to listening, although she still has to remind me somethings. -- JohannaRothman 2005.03.27

=========start of original 2002 discussion======== [text by JimBullock Moved from the ExtremeProgramming page]

I have to admit that the thought of pair programming makes me cringe, personally. It's kind of around having some overbearing yahoo leaning over my shoulder when I don't have a clue what we're talking about yet. Or being bored out of my skull for hours on end, while watching someone try to figure out the editor.

OTOH, in the big project mentioned above (in ExtremeProgramming discussion), we would often drag a peer over to "take a look at this", which could be anything from:

Is this the problem at hand?
I have no idea what to do here?
Will this work the way I have it here?
What's screwing up here, I don't get it?
And, actually, "Watch me type for a while."

From that experience I suspect that there's some precondition around having a common task definition and some level of common background to make "pair programming" work. I know that we did frequently say: "Let me drive." when working out some problem in the above example. Someone with a better clue at the moment would dive in and do the editing.

I'd like to hear something from the folks who've done XP about "yahoo avoidance". Perhaps there's a set of conventions in the practice that I don't yet know about, that address this issue. I'm a little curious why that hasn't come up yet.

- JimBullock, 18-Sept-2002

It sounds like Jim has already figured out pair programming -- work for a limited time (one or two hours) with a partner on a defined task, taking turns at the keyboard/whiteboard. Taking breaks as needed for solo thinking or bioneeds.

I haven't dealt with "yahoos" in an XP project, but I have heard that some some companies have had to fire or encourage to quit certain people who were not cooperating with others. In the cases I've heard about, the team became more productive after the non-cooperating person left.

KeithRay 2002.09.18

I feel better now. The XP types I got expose to asserted none of those constraints - in fact pushed back against some of them. Also there was pushback to working together - actually working at all, on anything but cutting code. So that's one puzzle down as I was having trouble reconciling my experince with XP with my perception that KeithRay, XP advocate exrordinaire, is a pretty reasonable guy.

As for "yahoos" and XP, KenEstes has a war story about this. Perhaps he'll share it with us, in wiki or in person. I have lots of non-XP "yahoo" stories, as I'm sure do others.

I am beginning to suspect, when it comes to methodologies, that one of the motivations is yahoo avoidance. A set of tools and practices is an administrative attempt to deal with a real problem. The right solution is be a manager, not an admini-drone, assert a performance standard, and eventually, if necessary, remove the dedicated yahoo. That's the job that the manager took, isn't it?

I also suspect that some roles are more yahoo sensitive (and yahoo attracting, like architect for example?) than others. Further that perhaps the yahoo sensitive roles vary by both by methodologies, and problem space. Shucks. That boils down to "There is no magical uber-methodology.", a special case of "There are no silver bullets." Here I thought I was on to something.

- JimBullock, 18-Sept-2002

The "yahoos" I've paired with have tended to be smart people who couldn't (or wouldn't) slow themselves down to match impedances with slower people. Coming into a new domain, or new part of a system, I usually go slow until I get a mental map constructed. When pairing with someone who insists on speeding along, I get frustrated, because there's too much stuff coming at me too fast, and I don't yet have the right mental buckets to park stuff in. On one such occassion, after escalating through increasingly loud "Please SLOW DOWN" pleas, I reached out and turned the monitor off. An eruption ensued. After my partner had calmed down, we had a talk about the purpose of pairing. It didn't take, and I didn't pair with them again.

In retrospect, I suspect that two big factors were at play. One was the reward structure, which still favored individual heroics. The other (and this is mindreading based on observation) is that this person strongly valued the personal groove (flow state) they got into when coding, believed they would be giving this state up while pairing, and resented it.

Pairing does break one type of flow, but replaces it with another, where the interruptions are supportive of the work at hand.

DaveSmith 18 Sep 2002

I suspect that there's some precondition around having a common task definition and some level of common background to make "pair programming" work.

It's definitely not about people inflicting their presence on one another. Paired programming in XP presupposes all the other activities which make programming intentional, purposive work : keeping the design simple and modular, working to a functional test which clearly delineates the functionality requested by the customer, and within that to one small unit test after the other, clearly delineating what it means for the program being written to be "correct".

Within that, pairing requires in addition that people pairing on a task should match mental velocities, divide the job of paying attention among them - driver paying attention to details and navigator paying attention to the map - and continuously review code quality as the code is being written.

But actually, the best analogy I can think of is to contract bridge. (Actually, to the French "belote coinch�e", which is a close equivalent.) You play with a partner because that's way more interesting and creative than, say, War or maybe even Poker. And you have rules about announcing bids and opening and so on, but the bidding rules are not a straightjacket; they are a framework of convention which enables good communication between partners in order to win the game. (And neither are the rules of play a straightjacket; they are a framework of expectations, of "realities" of the game which let you effectively predict the outcomes of bidding a certain way, even while you know that such predictions can never be certain.)

LaurentBossavit 2002.09.19

Dave talks about fit between potential pairs as one criteria for pair programming - or, more precisely, for picking another to pair with. I have not explicitly programmed in a pair - I can remember times when I was working with someone else, usually on a problem, when we tooks turns "driving". Is there a set of things that might lead one to decide to do pair programming? BobKing 2002.09.19

One advantage of pairs is that you don't have to stop for each new loose end when you're driving - one can keep the "TODO" list while the driver completes the main flow without bouncing for flow interruptions.

The Driver & Partner allows one to stay deep and continuous while the other views wide perspectives.

Lisa Crispin on StickyMinds discusses being a tester using pair-programming on an XP project. See her article or visit the Roundtable discussion at http://www.StickyMinds.com

I found it interesting to see a different role using the pair-programming technique to advantage. Once an organization sees pair-programming as a usual technique, other roles can borrow a set of eyes for design, architecture, testing or planning with little fuss. The continuous review effect is pretty powerful.

--BobLee 2002.09.19

Bob King: I have not explicitly programmed in a pair - I can remember times when I was working with someone else, usually on a problem, when we tooks turns "driving".

Sounds like pair programming to me. It's something many of us have done at some point, but without the label to hang on it.

DaveSmith 19 Sep 2002

Dave, whenever you think about coding, do you want to do it in a pair? -- BobKing 2002.09.20

I do a lot of solo programming, but pair when I can. I learn a lot by pairing with someone, or at least watching over their shoulder and asking questions. Pairing is a great way to swap little tricks and techniques, and occassionally some bigger ones. And there's something about being the second pair of eyes that makes it easy to spot problems as they fly off someone else's fingertips. And it's easier on me to have that second pair of eyes sitting next to me, rather than looking over my shoulder.

DaveSmith 21 Sep 2002

Is pair programming more productive? (by productive, I guess I mean more workable code into use faster) We probably could have a another thread on what it means to be a ProductiveCoder....

BobKing 2002.9.21

There's a tradeoff when pairing. My coding speed is diminished, but the end product usually gets into a working state quicker, with much less integration debugging. A good pair will keep each other honest on little things like checking for and dealing with error conditions, trying simpler ideas ahead of more complex ones, and *cough* writing test cases. A second set of eyes catches a lot of stuff that would be more expensive to catch downstream, and can be on the lookout for refactoring opportunities (e.g., "We're doing the same thing twice here and there. It's time to lift that into a method of its own.")

When I'm coding by myself, I often get pretty far into my head, and will often chase bright, shiny little diversions, then snap out of it and realize that I haven't touched the keyboard for 15 minutes. I also have to stop and look things up quite a bit (details from use cases, APIs, etc.). When pairing, I don't drift off into fantasy land as much (or as long), and a second set of eyes and hands can be used for parallel lookup ("hey, does the use case say anything about handling this error?"). The overall effect is a steady pace, with more "honest" code.

Where pairing doesn't work is when philosophical differences can't be resolved. There are a few people who I've spend most a session arguing with.

Pairing can also appear to slow things down when a lot of skills transfer needs to happen to get one half of the pair up to speed. It depends on how you measure productivity.

DaveSmith 21 Sep 2002

========end of 2002 discussion========

Since that last thread, I've been with a small startup that uses eXtreme Programming (and some SCRUM). 90% of our development is done in pairs (and anything done "singleton" gets an extra set of eyes on it before it gets checked in). Pairing works out very, very well for us, particularly in bringing new people up to speed. (And even the old guy gets to learn new tricks.) We avoid personality mismatches by a screening process that includes pair programming with the candidate.

Triplet programming is rare at our shop, but not unknown. We usually "assign" tasks by having a pair pull the next highest priority story card off of the work queue. Sometimes that means that a pair needs to bring in an expert as a third for a while, though usually we'll swap pairs if that happens. I got pulled into a hairy database deadlock problem last week, and swapped partners to work the problem.

Aside from social aspects, there's an economic model behind pairing. Roughly stated, it takes developer hours as input and completed work (including rework, which pairing minimizes) as output. When more than two people conribute, the ratio of completed work vs. time in goes down. (I'll look for the reference, though I think it's in David Anderson's , a book which I thank JeffMcKenna for recommending.)

We've just started doing something fun with pairing. The game is "ping pong". One person writes the unit test, and then hands the keyboard over to their pair, who (having first agreed that the test is appropriate and legitimate) writes code to make the test pass. Once the pair is happy with the result, roles reverse. And back and forth it goes, until the story has been implemented. We got the idea indirectly from folks at Object Mentor. Early reports suggest that it ups the level of engagement, attention, and enjoyment. We'll modify the practice if we find people playing "gotcha", but I doubt that'll happen in our team.

DaveSmith 2005.03.27

Updated: Monday, March 28, 2005