Pair programming is challenging for uninitiated developers. It has long been considered to yield higher quality code but many developers avoid it because of the challenges and the changes to their workflow. Ping Pong Pair Programming, however is a technique that is easy to learn, addresses the frustrations of traditional pair programming, and encourages other development practices that also yield higher quality code. In this talk we describe the challenges of traditional pair programming, how Ping Pong Pair Programming overcomes them, layout the basics of Ping Pong Pair Programming and then demonstrate how it works in practice.
For the last nine years we’ve worked together coaching teams on XP
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
ANTHONY - Here are some of the issues developers have with Pair Programming we have heard over the years
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
ANTHONY Now we have the opposite problem….
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
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
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
ANTHONY There’s a lot wrapped up in this statement…
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
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
ANTHONHY Now let’s talk about Ping Pong Pair Programming
ANTHONY Ping Pong Pair Programming is the combination of two of the 12 XP practices:Pair Programming Test-Driven Development
NICK If anyone needs a TDD refresher, let’s discuss the basics quickly
NICK And now when TDD gets laid over Pair Programming it looks something like this
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.
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
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.
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
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
ANTHONY Notice that not a single step takes longer than 2 minutes
Step 1 – Anthony –
Step 2 – Nick https://youtu.be/WujNniqzf9U
Step 3 – Anthony – https://youtu.be/OoSvlJv24hE
Step 4 – Nick – https://youtu.be/Kl6UbPtJNGo
STEP 5 – Anthony – https://youtu.be/kUkD_Ak6PLc
STEP 6 – Nick https://youtu.be/5VEuhMLS_Mk
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.
STEP 7 – Anthony – https://youtu.be/6coH9P0Yuxg
STEP 8 – Nick https://youtu.be/CSzFSzsKaXM
Step 9 – Anthony – https://youtu.be/1gfihiwx8dw
Step 10 – Nick – https://youtu.be/4SfL6WWsCjo
Step 11 – Nick - https://youtu.be/1eFAMNBStCo
Step 12 – Anthony - https://youtu.be/P_u5OWjAcWo
The Ultimate Developer Collaboration Technique: Ping Pong Pair Programming
The Ultimate Developer Collaboration Technique
PING PONG PAIR PROGRAMMING
Heart of Agile Pittsburgh – April 27, 2017
Acquisition - 2013
Nine years of experience working together, practicing and coaching teams on XP
Ping Pong Pair
2. Write only
code to make the
1. Create a failing unit test (not
compiling counts as a failing test)
3. Refactor only when all unit tests are passing
Writes a failing 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
Talking about everything I’m
doing will slow me down.
The Bill Payer App
Allows users to view, manage, and autopay
As a bill 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
As a bill 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
We love talking about Agile Software Development, XP,
developer practices, helping development teams improve
how they work and their code, etc.
Github Repo – Each Step of Ping Pong Pair Programming Demo