Montreal Xp Pair Programming Presentation

PairProgramming: How to start and how to love it!

• Introduction to PairProgramming
  • What did you experience?
  • What is PairProgramming?
    • Mental state while PP, Symbiosis
    • PP allows us to leverage the benefits of the other practices by encouraging us to apply them
  • What is PairProgramming not?
    • PairProgramming is not only two people in front of a computer trying to debug!
    • Pilot and Co Pilot vs. Driver and Passenger (more active terms illustrate the true nature of the relationship)
  • Egoless Work, Communication, Feedback and Courage
    • That's ok to be imperfect (and do not be afraid to say / admit it) [looks like confronting fear, having courage)
    • PP (and Egoless Work in general) battles natural tendencies in programmers (solo work)
• How to start PairProgramming
  • How to sell it
    • Efficiency (cost and benefit)
    • PP as a culture. Need Support from peers / company? --> XP as a culture?
  • How to do 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.

• The physical setup / environment for PP
• Reconaissance du travail? Evaluation du travail par superieur/superviseur? (Is this PP vs. CodeReview? -- Iain)
• be rested (may be PP vs other XP practices)
• Building relationship, "learning the other"
• That's ok to be imperfect (and do not be afraid to say / admit it) [looks like confronting fear, having courage)
• Teaching-Learning experience. We are learning here. This shows a cyclic or recursive experience.
• First, listen to understand, then be understood (covey)
• Well being (bien dans sa peau) --> humility
• Trust up front, credibility / trust account (As in Seven Habits / Covey): Earn it, Learn it, technical debt, on both side
• Be present to PP, or PP will force people to be present (as in peer pressure?)
• PP as a culture. Need Support from peers / company? --> XP as a culture?
• Switching with another peer: Why? Switching context provoques Mindfulness
• How to love PairProgramming
  • The MentalStateCalledFlow when pairing
  • Building relationship, "learning the other"
  • Teaching-Learning experience. We are learning here. This shows a cyclic or recursive experience
  • Be present to PP, or PP will force people to be present (as in peer pressure?)
  • Mental state while PP, Symbiosis
  • PP as a culture. Need Support from peers / company? --> XP as a culture?
  • Switching with another peer: Why? Switching context provoques Mindfulness
  • Choosing rules vs. having them imposed on you
  • rights vs. responsibilities
  • Rights
    1. Switch keyboard
    2. Call for a break - after the break, resume where you left off
    3. Ask for directions / intentions ("what are you doing / why are you doing that?")
    4. To be listened to / to have your intentions understood
    5. To ask what your rights are
    • Transparency about the rules -> Pilot / Copilot bill of rights
  • PP with hostile partner
    • ("I refuse to have anything to do with this PP crap")?
• PairProgramming Miscellanea
  • PairProgramming and other Xp Core Practices - What are the links between PairProgramming and other practices? How does PairProgramming enable the other practices and how do they enable PairProgramming? See also p66,67 of XPE
  • pp expected % of total time
  • pp with odd number of team members
  • pp in large team, small team
  • pp in distributed environment
  • no test no problem! (avoid trying to solve a problem without defining a test)
  • Peer Pressure (also pp;-)
  • Recognizing that is draining, can you be use it so it is less draining?
  • Adaptation curve / learning curve of pp
  • Efficiency code and test or code with test
• Conclusion
  • What's next / conclusion - pair managing?
• Bibliography and further reading
  • Anything (almost) by LaurieWilliams
  • PairProgramming
  • PairProgrammingTipsAndTricks
  • RecordYourCommunicationInTheCode

---

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

---

• What about trying to list why pair programming does not sell very well?

---

From the discussion of Tuesday:

• The values are driving the practices (maybe as an introduction for pp presentation)
• Expressing intentions
• Letting others lead
• Asking others to remind me of my rights - rights are given not taken. You cannot remind somebody that they gave you a right. You have to ask them if they still afford you that same right.

---

MontrealXpUsersGroup