Ping-Pong: Pairing isn't just an Olympic Sport
Many of us have been enjoying the delayed Tokyo Olympic Games the last couple of weeks. And many people watching the table tennis (or ping pong) would not immediately associate it with software development. But "ping-pong pairing" is something many teams at Zuto incorporate into their day-to-day lives.
What is "ping-pong" pairing?
Pairing is a common practice in software development. This is where two developers will work on the same ticket or piece of work, usually with one developer "driving" by writing the code and another one "directing" which means to instruct.
Ping-pong pairing is another structure. This is where one developer will write a unit test. This will fail, in line with the Test Driven Development practices. The second developer will then write the code which will make this failing unit test pass. Once the test is passing, the developers will switch roles.
What are the benefits?
Ping pong pairing allows both developers the opportunity to work on the unit tests and the code. It ensures that both get to work on the code, as the structure prevents one developer from doing all of the work. This is especially beneficial when a developer might be new to TDD or unit testing.
Another benefit of ping pong pairing is that it improves understanding of the code. By focusing on small amounts of code, because each unit test is taking one at a time, and will by nature only focus on a small area of code; it will improve the understanding of the code.
This structure of pairing drives discussions between developers. The rapid code changes and role switching will encourage both developers to keep communication open, while traditional pair programming may find one developer driving and talking more.
Are there downsides?
During these covid times when people are working remotely, the main downside can be the need to pass the code back and forth so often. There are various ways to do this, whether developers use a live-sharing software, or the code is pushed to Github etc and pulled down by the other developer. This can feel tedious or may be time consuming when developers are on a short deadline or there are issues with any software that is being used.
Overall in my experience I would say that since being introduced to ping-pong pairing my learning has been far more effective. Although it can be intimidating at first, especially for someone who wasn't familiar with unit testing when I first started at Zuto, once I got into the flow and increased my confidence in asking questions it was quite enjoyable!