Download to read offline
More Related Content
![How to don[1]](https://cdn.slidesharecdn.com/ss_thumbnails/howtodon1-110526140200-phpapp01-thumbnail.jpg?width=640&height=640&fit=bounds)
Similar to The Ultimate Developer Collaboration Technique: Ping Pong Pair Programming
The Ultimate Developer Collaboration Technique: Ping Pong Pair Programming
- 1. The Ultimate DeveloperCollaboration Technique PING PONG PAIR PROGRAMMING Anthony Sciamanna @asciamanna Nick Goede @ngoede Heart of Agile Pittsburgh – April 27, 2017
- 2. Nick Anthony 20082005 Acquisition -2013 Early 2014 Nine years of experience working together, practicing and coaching teams on XP XP Organization 2000
- 3.
- 4. Pair Programming isreally interesting, everybody talks about it but no one does it. - Bryan Helmkamp, Founder and CEO Code Climate, Baruco 2013 “
- 5. Traditional Pair ProgrammingChallenges What we’ve heard…
- 6. I never getto type!
- 8. Whenever I amdriving my pair just looks at their phone.
- 10. I can’t everget into flow when pairing.
- 12. Talking about everythingI’m doing slows me down.
- 13. Developers new toTDD & pair programming think they have to solve the big problems before they start pairing
- 14. Programming By Coincidence AKADebugger Driven Development
- 15. Ping Pong PairProgramming
- 16. Pair Programming Test-Driven Development Ping PongPair Programming
- 17. 2. Write only enoughproduction code to make the test pass 1. Create a failing unit test (not compiling counts as a failing test) 3. Refactor only when all unit tests are passing Ping Pong Pair Programming
- 18. Nick Anthony Writes afailing test Makes the test pass Writes the next failing testMakes the next test pass Only when all tests pass either person can refactor Continue until both people agree there are no more tests to write
- 19.
- 20. I never getto type!
- 21. Whenever I amdriving my pair just looks at their phone.
- 22. I can’t everget into flow when pairing.
- 24. Talking about everythingI’m doing will slow me down.
- 26. DEMO The Bill PayerApp Allows users to view, manage, and autopay their bills
- 27. USER STORY As abill payer I want my mortgage bill paid on its due date or the first business day after its due date (when it falls on a non- business day), so that I can maximize the time that I keep my money in my account without incurring penalties
- 28.
- 29.
- 30.
- 31.
- 32.
- 33.
- 34. USER STORY As abill payer I want my water bill paid on its due date or the first business day before its due date (when it falls on a non-business day), so that I can maximize the time that I keep my money in my account without incurring penalties
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41. Try Ping PongPair Programming!
- 42. CONTACT US! We lovetalking about Agile Software Development, XP, developer practices, helping development teams improve how they work and their code, etc. Nick Goede @ngoede ngoede@gmail.com http://nickgoede.com Anthony Sciamanna @asciamanna asciamanna@gmail.com http://anthonysciamanna.com Github Repo – Each Step of Ping Pong Pair Programming Demo https://github.com/asciamanna/ping-pong-pair-programming-talk
Editor's Notes
- #3 ANTHONY For the last nine years we’ve worked together coaching teams on XP
- #5 ANTHONY This quote is from Bryan Helmkamp, one of my favorite experts on code quality. From the Barcelona Ruby Conference in 2013 The context of the quote is that he is talking about his “Software Quality Playbook” and discusses pairing. He goes on to say that he recommends pairing and doesn’t do it so he his part of the problem. This is consistent with what Nick and have experienced Most developers don’t want to pair Most of those that have paired don’t learn how to do it effectively so they rarely do it This differs from our experience with Ping Pong Pair Programming They think it is only for bringing junior developers up to speed and that’s it “We Pair only when appropriate.”…and that’s not very often Our experience with Ping Pong Pair Programming is quite different Teams that practice Ping Pong Pair Programming typically find it very effective and stick with it
- #6 ANTHONY - Here are some of the issues developers have with Pair Programming we have heard over the years
- #7 NICK
- #8 NICK The Keyboard Dominator One Person does all the typing in the pairing session the other has to wrestle control away eliminating opportunities for quality collaboration The pairing session is very one sided The Keyboard Dominator is usually accompanied by the Code Spectator --- the other half of the pair. This person is there to watch but not much else
- #9 ANTHONY Now we have the opposite problem….
- #10 ANTHONY The Disengaged Pair While one developer is working on the problem the other is checking their phone, reading tweets, planning their evening, etc. THIS IS REALLY SOLO WORK The other person gets a break from work for several hours This is less effective than working alone
- #11 NICK Flow – when the developer(s) have the entire problem state in their head and they are making the most effective progress on the solution. Any interruption will set them back
- #12 NICK ONE SOURCE IS WHAT WE CALL MISMATCHCED PAIRS One developer in the pair knows more than the other about the problem their solving, the domain, the technology than the other – struggles getting the other person contributing. Developers think they either need to coach or make efficient progress on the problem but not both Developers conclude it is easier to achieve flow and do their best work if they can just work alone
- #13 ANTHONY There’s a lot wrapped up in this statement…
- #14 ANTHONY This is just not true. When effectively pairing and using TDD the pair solves the big problems together (and adjusts as needed) while incrementally building the solution. Developers think pairing is just to bring junior developers up to speed and everything has to be scripted ahead of time. Don’t want any surprises in the pair
- #15 ANTHONY Some developers struggle with communication while pairing because they are doing what Andy Hunt and Dave Thomas call Programming By Coincidence. Some devs just need to work understanding existing code quickly And communicating their technical ideas to others It comes as no surprise These teams typically struggle with coaching
- #16 ANTHONHY Now let’s talk about Ping Pong Pair Programming
- #17 ANTHONY Ping Pong Pair Programming is the combination of two of the 12 XP practices: Pair Programming Test-Driven Development
- #18 NICK If anyone needs a TDD refresher, let’s discuss the basics quickly
- #19 NICK And now when TDD gets laid over Pair Programming it looks something like this
- #20 NICK
- #21 NICK Ping Pong pair programming creates a natural rhythm with pre-established switching moments. If you are careful to follow TDD switching should happen every few minutes or so at most.
- #22 ANTHONY These regular switching intervals helps prevent pairs from getting distracted and thinking about possible refactorings If you know you are going to be typing again in a minute or two you’ll be thinking about the next test Taking the smallest steps possible to make a test fail and then pass gets the pair engaged in the problem quickly - As the pair progresses they can start taking bigger steps
- #23 NICK
- #24 NICK Ping Pong Pair Programming Welcomes Mismatched Pairs --- Every Pairing session is opportunity to share knowledge, collaborate, coach and Mentor While making progress on the solution. But works equally well if pairs are of similar skill set or if they aren’t.
- #25 ANTHONY The incremental & collaborative nature of Ping Pong Pair Programming helps developers practice Addressing problems and designs incrementally Working collaboratively on solutions Read and understand existing code quickly Communicate technical problems and solutions effectively to others YOU CAN’T PROGRAM BY COINCIDENCE AND PING PONG PAIR PROGRAM Less programming by coincidence will yield higher quality code
- #26 ANTHONY Practicing Ping Pong Pair Programming helps create a culture of mentoring and coaching on development teams Every team we worked with that practicing Ping Pong Pair Programming had a strong mentoring culture
- #27 ANTHONY Notice that not a single step takes longer than 2 minutes
- #28 NICK
- #29 Step 1 – Anthony – https://youtu.be/WZsLNrnS4yk
- #30 Step 2 – Nick https://youtu.be/WujNniqzf9U
- #31 Step 3 – Anthony – https://youtu.be/OoSvlJv24hE
- #32 Step 4 – Nick – https://youtu.be/Kl6UbPtJNGo
- #33 STEP 5 – Anthony – https://youtu.be/kUkD_Ak6PLc
- #34 STEP 6 – Nick https://youtu.be/5VEuhMLS_Mk
- #35 ANTHONY Notice the only differences from the last story are listed in yellow. This would be something Nick and I would discuss in the pair and it would inform our refactoring decisions towards our preferred software design.
- #36 STEP 7 – Anthony – https://youtu.be/6coH9P0Yuxg
- #37 STEP 8 – Nick https://youtu.be/CSzFSzsKaXM
- #38 Step 9 – Anthony – https://youtu.be/1gfihiwx8dw
- #39 Step 10 – Nick – https://youtu.be/4SfL6WWsCjo
- #40 Step 11 – Nick - https://youtu.be/1eFAMNBStCo
- #41 Step 12 – Anthony - https://youtu.be/P_u5OWjAcWo
- #43 BOTH