Pair programming
Upcoming SlideShare
Loading in...5
×
 

Pair programming

on

  • 249 views

 

Statistics

Views

Total Views
249
Views on SlideShare
249
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Pair programming Pair programming Presentation Transcript

  • Share ExperienceWhat are the benefits?● Faster development● Better code design● Reduces bugs● Peer reviewed code● Tougher tasks solved much faster
  • Pair Programming Mind Map
  • Pairing tips
  • 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 andplanning 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 toimprove.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 healthydisagreement/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 screenand sharing the keyboard and mouse. Slide the keyboard -- dont 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 thatis 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 workwith you.Warm cookies and cold milk are good for you. Periodically, taking a break is important for maintaining the stamina for another round of productivepair 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 thanthe 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 withbetter quality.
  • Manners● Pass the keyboard liberally.● Allow the person on the keyboard to complete a block of code beforeasking a question or making a comment.● Don’t read email, talk on or play with your cell phone or otherdistracting 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 histhought and then offer your suggestions for improvement orrefactoring.● If you get into a heated debate or discussion, ask a third party tointervene to help resolve the situation or propose a short break andthen use that time to evaluate the importance of the discussion todetermine 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.
  • Our pair programming implementation
  • Pair programming ? Pair fun
  • Side effects
  • Top Ten● Interrupt every time your partner starts doing something in a way other than how youd do it.● Once you wrestle the keyboard away, delete your partners last edit immediately. Then do what you were thinking ofinstead.● If your partner objects, ignore it, talk over it, flim-flam around it, claim to be the XP expert, and then accuse him of playingthe 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 youhavent 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 aprolonged argument about it.● Complain before your partner does something wrong. Create elaborate theories about their failings. Never forgive, neverforget.● Suffer annoyances in silence until you just cant stand it any more, then blow up. For bonus points go red in face and stormout without explanation.● Begin every pairing session with a long discussion of all problems you ever experienced together. Insist that all problemsbe resolved before a line of code is cut. For bonus points, conduct this conversation under time pressure and outsidenormal work hours when your partner should be curled up at home with their poor neglected spouse.
  • 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 generalpairing 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 numberof tasks that dont.● 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.
  • PersonaThe Silent PartnerHere the co-pilot pays no attention to the work at hand, sits back and lets the pilot get on with it. Whilstgiving the illusion of pairing, the co-pilot actively hands off responsibility to their partner. Symptomsmay 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. Atworst 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 usingdifferent 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 somecases 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 isdifficult and they either become “Dictator”, “Silent Partner” or there is an “Amicable Separation”.
  • Pair programming formula1+1<2
  • Pair Hero gamePair hero is a collaboration game for pair programming where each player getsa turn writing tests, code and scoring points. Each game is 25 minutes long soyou can keep your pomodoro breaks.
  • Pair Hero gameScoring● 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.
  • Happy pair :)