Your SlideShare is downloading. ×
Pair Programming :: Blip 2014
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Pair Programming :: Blip 2014

142

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
142
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • NCIS 2 IDIOTS 1 KEYBOARD video
  • eXtreme Programming (XP)
    Software development methodology
  • code is produced by two people programming:
    on one task
    on one workstation
    Two keyboards (optional)
    Two mice (optional)
    Two monitors mirroring (ideally)
  • How should the driver and navigator seat?
    Which hardware should they have to pair programme effectively?
  • All the times:
    In front of a working station

    Except in:
    meetings (finishing each other sentences)
    Bathroom (taking a leak)
  • Collective code ownership… everybody gets a chance to know and “own” all the code
    Bus factor
    Beginners mind
  • Collective code ownership… everybody gets a chance to know and “own” all the code
    Bus factor
    Beginners mind
  • Engagement / Commitment
    Valuable Stand ups
    Better integration of new team members
  • Should I stay or should I go?

    It really depends how obsessed you are with reviews…but I would say no.
    One of the members of the pair is already reviewing
    With proper rotation everybody gets a chance to review the code
  • Less bugs
    More fun
    Less distractions
    Less interruptions from “outsiders” (changed from stopping one dev to stopping two)
    Less slacking on important stuff (testing, coding properly, adding comments, etc...)
  • Because you are pairing:
    you have better ideas
    stay in the zone for longer
    More courage to take “risky”/”unconfortable” tasks
    Opportunity to learn and to teach
  • [Image] Dude coding and listening to music

    [Image] Dude coding on workstation and having facebook on the laptop
  • No music (at least headphones)
    No youtube
    No facebook
    No twitter
    No instagram
    No tumblr

    Basically No social crap

    (your manager is going to love this part)
  • * Nop!
    * You must:
    Be willing to give it a try
    Be social
    Be confident
    Embrace/deal with partners feedback
    Manage conflict
    Accept differences (not everything will be like you want)
    * It’s quite exausting
    It’s not rainbows and unicorns
    You will have a learning curve ahead
  • BUT... It should be highly recommended!

    (Story at sky where the team stick to pp because of not wanting to do code review.)
  • The non believers think so:
    Twice the salary / cost?
    Half the speed?
    So what about:
    Bugs?
    Technical debt?
    Bus factor?
    Team spirit? Morale?
    WIP limit?
    It wont be expensive on the mid/long term
  • BSkyB
    2degrees network
    NotOnTheHighStreet.com
    Virgin Media
    Orange
    O2
    eBay
    Hashrocket
    Pivotal Labs
    Facebook
    Square
    Twitter
    Groupon
    SaludOnNet
    Feelunique.com
    CustoJusto.pt
  • * Couple of days a week
    * Just one team
    * Just one pair (in a team)

  • Transcript

    • 1. Pair Programming
    • 2. Who am I? @_pedro_torres | pedrogustavotorres.com Pedro Gustavo Torres
    • 3. Or even this?
    • 4. A little bit of background
    • 5. What is Pair Programming? • code is produced by two people programming: – on one task – on one workstation • Two keyboards (optional) • Two mice (optional) • Two monitors mirroring (ideally)
    • 6. Driver…
    • 7. …navigator
    • 8. Change roles multiple times a day
    • 9. Change roles multiple times a day
    • 10. Change roles multiple times a day
    • 11. ¡Quiz time! In which scenarios are the developers properly pairing? A B C D
    • 12. Setup #1
    • 13. Setup #2
    • 14. Setup #3
    • 15. Setup #4
    • 16. All the times in front of…
    • 17. …except in…
    • 18. …and in!
    • 19. Task BTask B Task ATask A Rotation between pairs Monday Wednesday
    • 20. Pair rotation lader Rachel Davies, Agile Coaching
    • 21. Collective code ownership…
    • 22. …bus factor…
    • 23. …beginners mind
    • 24. Engagement / Commitment…
    • 25. …valuable stand-ups…
    • 26. …better integration of new team members…
    • 27. …limit WIP…
    • 28. … to skip code reviews?
    • 29. Less bugs…
    • 30. …more fun…
    • 31. …less distractions…
    • 32. …less interruptions…
    • 33. …less slacking…
    • 34. …and comfort zone wise…
    • 35. …bigger comfort zone!
    • 36. Two heads think better than one
    • 37. “Common” habits…
    • 38. …no music / social “stuff”
    • 39. So is Pair Programming for everyone?
    • 40. It should not be imposed
    • 41. Remotely works?
    • 42. Are estimations affected?
    • 43. What about size or length of tasks?
    • 44. Is it €xp£n$ive?
    • 45. Is it only for mature teams?
    • 46. Does it scale?
    • 47. Companies that use it?
    • 48. Scholars and hands-on fans?
    • 49. Maybe slow…
    • 50. …or all in!
    • 51. Thank you Next time I’ll pair present! 

    ×