Ping Pong Pair Programming

I don’t know who first coined the name Ping Pong Pair Programming but I know from the first time I heard of it, I was convinced. It seems likely that PPP (ping pong pairing) arose out of a need to address some of the challenges of pair programming. Namely, the difficulty of maintaining attention when you are not the one at the keyboard.

PPP is also a derivative of Test Driven Development. In TDD, you write your test first and you never write code for a feature that is not in a failing test already. It is a great way to ensure a robust test suite for all of your development. TDD works like this: 1) write a test, 2) confirm that it fails, 3) write code to make the test pass, 4) confirm the test passes, 5) confirm no other tests are broken, 6) refactor mercilessly. TDD is very effective but there are challenges. It is very easy to shortcut your tests a little by writing more than you really need. It is also easy to avoid testing the really hard cases.

Ping pong pairing works with two people. Let us call them Bob and Tom. The day starts with Bob at the keyboard. All the tests pass. Bob writes a test. Bob confirms it fails. The keyboard passes to Tom. Tom works on making the test pass with Bob at his side, helping him along. Tom finishes his implementation and confirms all the tests pass. Tom writes a new test and confirms it fails. The keyboard returns to Bob.

PPP is very similar to TDD in that it is made up of te same steps. The difference is that after a failing test is implemented, the other developer takes control. This can develop into a friendly game. Bob tries to write a good test that forces Tom to implement real and valuable functionality. Tom tries to pass Bob’s test with the simplest thing that could possibly work. The harder Bob and Tom try to push the difficult work to the other person, the more robust the test suite and the finished code become.

Ping pong pairing addresses the psychological challenges in both pair programming and test driven development. Because control switches so frequently, partners stay more engaged in what is going on. Because you don’t have to implement the code for your own tests, you are much less likely to take shortcuts just to allow yourself to get by.

Ping pong pairing is hard work and is has been very rewarding when I have done it. It results in much better code and more robust tests. It also helps to keep things moving at a good pace. If you pair program, I strongly recommend you try your hand at PPP.

See more progress on: Create a form of ping pong programming for distributed teams.