1. The document describes a pair programming technique called "Ping Pong Pair Programming" where two developers take turns writing a failing test case and then production code to pass that test, refactoring only when all tests pass.
2. It addresses common challenges with traditional pair programming such as one partner not actively participating. Ping Pong aims to solve these by having partners take turns driving and keep each other engaged.
3. The document demonstrates Ping Pong through a sample application for managing bill payments, with the presenters explaining their process and providing video links to each step. They encourage trying Ping Pong to experience its benefits.
The Ultimate Developer Collaboration Technique: Ping Pong Pair Programming
1. The Ultimate Developer Collaboration 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
17. 2. Write only
enough production
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 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
26. DEMO
The Bill Payer App
Allows users to view, manage, and autopay
their bills
27. USER STORY
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
34. USER STORY
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
incurring penalties
42. CONTACT US!
We love talking 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
Notas del editor
ANTHONY
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
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
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
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
NICK
Step 1 – Anthony –
https://youtu.be/WZsLNrnS4yk
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.