Pair programming

20

Click here to load reader

Transcript of Pair programming

Page 1: Pair programming
Page 2: Pair programming
Page 3: Pair programming
Page 4: Pair programming

Share ExperienceWhat are the benefits?

● Faster development● Better code design● Reduces bugs● Peer reviewed code● Tougher tasks solved much faster

Page 5: Pair programming
Page 6: Pair programming

Pair Programming Mind Map

Page 7: Pair programming

Pairing tips

Page 8: Pair programming

Guideline Summary:Share everything. All contributions, whether great results and errors, are “ours”, not “yours” or “mine”.

Play fair. One person “drives” (has control of the keyboard or is recording design ideas) while the other is continuously reviewing the work and planning ahead. Stay fairly close to 50-50 on driving. Let the less experienced partner start and maybe drive a little more.

Don’t hit your partner. But make sure your partner stays focused and on-task.

Put things back where they belong. Put negative judgments in the trash: Be positive about you and your partner. For both, this is an opportunity to improve.

Clean up your mess. >Watch over the shoulder and you are really likely to find a large number of your errors!

Don’t take things too seriously. If your partner picks out a bunch of errors as you type, be glad. But do not always agree. Have healthy disagreement/debate. Finding the fine balance takes adjustment.

Say you’re sorry when you hurt somebody while moving furniture. Sit side-by-side and program, simultaneously viewing the computer screen and sharing the keyboard and mouse. Slide the keyboard -- don't move the chairs.

Wash your hands of skepticism before you start. Being skeptical can be a self-fulfilling prophesy. Buying in and “jelling” can lead to a whole that is greater than the sum of the parts.

Flush. If you work on some parts independently either discard them (flush) and start over together or have the partner very carefully review the work with you.

Warm cookies and cold milk are good for you. Periodically, taking a break is important for maintaining the stamina for another round of productive pair programming.

Be aware of the power of two brains. Experiences show that, together, a pair will come up with more than twice as many possible solutions than the two would have working alone. They will then proceed to more quickly narrow in on the “best” solution and will implement it more quickly and with better quality.

Page 9: Pair programming

Manners

● Pass the keyboard liberally.● Allow the person on the keyboard to complete a block of code before

asking a question or making a comment.● Don’t read email, talk on or play with your cell phone or other

distracting behavior while actively working.● Don’t touch the screen.● Rather than grabbing at the keyboard or mouse, ask, “May I?”● Instead of sighing or huffing, keep quiet until your partner finishes his

thought and then offer your suggestions for improvement or refactoring.

● If you get into a heated debate or discussion, ask a third party to intervene to help resolve the situation or propose a short break and then use that time to evaluate the importance of the discussion to determine your next steps.

● Rather than gobbling down your afternoon snack, offer to share.● Instead of just quietly parting ways at the end of the pairing session,

thank your pair partner.

Page 10: Pair programming

Our pair programming implementation

Page 11: Pair programming

Pair programming ? Pair fun

Page 12: Pair programming

Side effects

Page 13: Pair programming
Page 14: Pair programming

Top Ten

● Interrupt every time your partner starts doing something in a way other than how you'd do it.● Once you wrestle the keyboard away, delete your partner's last edit immediately. Then do what you were thinking of

instead.● If your partner objects, ignore it, talk over it, flim-flam around it, claim to be the XP expert, and then accuse him of playing

the previous techniques. Better yet, accuse him of playing this one.● Pair on stuff that is ambiguous so that you can diverge in intent and context every step of the way.

(AmbiguityRequiresSpikes.)● Wait until your partner is half-finished expressing an idea. Then demand they stop and do something else. Explain that you

haven't seen a green bar in the last 2 hours.● Speak non-stop, so your partner never has a silence in which to speak, read code, or have a thought.● Demand silence except when absolutely necessary. When you misunderstand what your partner is doing you can have a

prolonged argument about it.● Complain before your partner does something wrong. Create elaborate theories about their failings. Never forgive, never

forget.● Suffer annoyances in silence until you just can't stand it any more, then blow up. For bonus points go red in face and storm

out without explanation.● Begin every pairing session with a long discussion of all problems you ever experienced together. Insist that all problems

be resolved before a line of code is cut. For bonus points, conduct this conversation under time pressure and outside normal work hours when your partner should be curled up at home with their poor neglected spouse.

Page 15: Pair programming

When Not to PairThere are several situations when it makes sense not to pair:

● When reading about a library that might help later on● Spiking a complex solution or debugging a tricky error with someone that has an experience gap. In general

pairing is not ideally suited for the combination of exploration and bridging an experience gap.● Not every task requires a pair; however, the number of tasks that require pairing is a lot higher than the number

of tasks that don't.● Research work

○ Pairing should not start until coding.○ If still in research part, it is prefered to be separated.

● Both have no idea how to implement project○ Two inexperienced people, working together, may reduce the productive ○ An inexperienced people need to pair with an experienced people.Page

● Trivial work○ We use pairing to increase productivity. If the work itself is trivial, pairing is a waste of resource.

● People hate each other○ If partners hate each other, pairing will become a disaster.○ We want paring to build relationship, not to hate each other more.

● One person is not around○ When one person is sick, or have to deal with some person affairs, the other guy may need to work alone. ○ We do not need a temporary pairing.

Page 16: Pair programming

PersonaThe Silent PartnerHere the co-pilot pays no attention to the work at hand, sits back and lets the pilot get on with it. Whilst giving the illusion of pairing, the co-pilot actively hands off responsibility to their partner. Symptoms may include excessive attention paid to a mobile phone, or conversations with other colleagues.The DictatorThis anti-pattern sees the pilot hogging the keyboard and ignoring any suggestions by the co-pilot. At worst the “Dictator” makes destructive comments. Ultimately this may result in the “Silent Partner” anti-pattern as the co-pilot becomes dispirited.The Amicable Separation or Pairing SeparatelyBoth individuals split to work on separate aspects of the current work item, sometimes even using different laptops at the same desk.Asleep at the WheelThis behaviour manifests itself when the pilot is basically acting as nothing more than a stenographer. They take no active part in the design of the code, relying on the co-pilot to direct their efforts, in some cases even to the extent of needing to be told what to type.The Lone WolfThis is the person who, for whatever reason, prefers to work alone. As a result pairing with them is difficult and they either become “Dictator”, “Silent Partner” or there is an “Amicable Separation”.

Page 17: Pair programming

Pair programming formula

1+1<2

Page 18: Pair programming

Pair Hero gamePair hero is a collaboration game for pair programming where each player gets a turn writing tests, code and scoring points. Each game is 25 minutes long so you can keep your pomodoro breaks.

Page 19: Pair programming

Pair Hero game

Scoring● Each passing Test + 10 points● Each refactoring + 2 points● Switch driver in less than 1 minute multiplies your score by 2● Switch driver in less than 30 seconds multiplies your score by 4Writing just enough code to pass the keyboard to your pair is highly rewarded!

Ping Pong ProgrammingThe game is based on possibly the most collaborative and fun of all the pair programming practices. The rules are simple:

● You write a test and make sure that it fails● I implement enough code to make the test pass● I write a test and make sure that it fails● You implement enough code to make the test pass● Goto 1Refactoring is done whenever the need comes up.

Page 20: Pair programming

Happy pair :)