Montreal Xp Pair Programming Presentation

PairProgramming: How to start and how to love it!

PairProgramming for the un-initiated

ReFactor as an intro to PP

  1. With inexperienced developers show before and after, "yours" vs. "ours" - destroy egotism. Green developers can be shown immediately that there is no value in not sharing and collaborating on everything. In some ways they should be easier to work with not having any of the pre-conceptions that a more experienced developer will have. On the other hand you may find it hard to get them to "drive" while you are pairing simply because of their unfamiliarity with the language or technology you are using. This is why we recommend that you start with some code that they wrote and ReFactor it with them.
  2. With experienced developers ask for help with your own code and ReFactor the code together. This will give them and idea of how ReFactoring works. They are (presumably) comfortable already with the language that you are using and thus are benefitting not from seeing your code but from seeing what you do with it. In addition, you will be able to gain some insight into your own code from their perspective.

Of the two options listed above, the second is obviously the preferred one. It is less confrontational and allows for a subtle adoption of the practice without ramming anything down anybody's throat.

In the same vein as the CustomerBillOfRights etc., we propose the Pilots Bill Of Rights and the Copilots Bill Of Rights:

Pilot's bill of rights

You have the right to:
  1. become the Copilot
  2. call for a break - after the break, resume where you left off - do not switch positions on the break
  3. ask for directions ("What are we doing? Why are we writing this?")
  4. to be listened to

Copilot's bill of rights

You have the right to:
  1. become the Pilot
  2. ask for directions ("Why did you implement that like that? What does this mean?")
  3. suggest / give new directions

Should we add a bootstrap right? the right to tell / review the right

Would this be the right to re-define / add / remove rights? I'm not sure that's really in keeping with the idea of a bill of rights that guarantees the presence of those rights. If you could remove a right then it's not guaranteed anymore. I may have misunderstood what you were saying though.

Should we have common rights? The right to ask the intentions. I think intentions should a preferred term.

I liked the intentions idea a lot. I don't remember exactly what we had said about it. Something about the right to express an intention? What do you mean by "the right to ask the intentions"? I think there are some common rights (like ask for directions) but maybe they belong in both separately or is that a violation of OnceAndOnlyOnce?

The right to ask to pair with someone else (on the same task) - to switch partners

Could you then simply select with whom you pair by invoking this right when somebody you don't like asks you to pair with them on something?

I just read the Chapter 23 of XP examined - The VCAPS Project: An example of transitioning to XP. (by Don Wells and Trish Buckley. p. 409 - 411 on Pair Programming.

This is very interesting. In brief: It is better to begin to learn pairing by pairing with someone of equal (or almost equal) technical competency (to avoid teacher-student on technical stuff too early). It is better to begin to pair with someone that have experience with pairing (to quickly understand what is pairing). Then, later, the teacher-student subrelationship may come and pairing with someone of different technical competency will be better.

Another concept is to practice the art of letting the others feel as if ideas were theirs (especially junior) without being manipulative.

For Don and Trish, they seem to really believe that pair programming is more a social activity...

From the discussion of Tuesday:

View edit of February 5, 2005 or FindPage with title or text search