Create a form of ping pong programming for distributed teams.

The paradigm of ping pong pairing can be used without pairing. I have been ping pong programming remotely with Pat Eyler for a couple weeks now and it has been tremendously effective. Basically, the process for ping ponging remotely is the same as ping pong pairing but instead of passing a keyboard back and forth, we check our code into Subversion. A typical scenario looks something like this:

Pat updates his code to make sure everything is current. He runs the test suite to see what the currently failing test is. After some analysis, he fixes the code and makes the test pass. Now, he checks his code into Subversion. Next, he writes a new test and confirms that it fails. Because he has to communicate the change to me, he checks his failing test into Subversion with a comment about the current test. Finally, he notifies me that the ball is in my court. It is my turn to repeat the process.

This style of development is more powerful than simple Test Driven Development for the same reasons I mentioned before. By posing tests for your opponent, you develop stronger tests than you do for yourself.

Remote ping pong does have its shortcomings though. In particular, it doesn’t deal with time imbalances very well. While Pat is implementing my test, I am doing nothing. If I have several hours to devote to coding and Pat only has a few minutes, I will spend a lot of time waiting for a test when I could be coding.

I want to address the time disparity concern by figuring out what works in ping pong and creating a model with all the benefits but without the time constrained challenges. In addition, I would like to figure out how to apply the principles of ping pong to teams of more than two people. A tenative name for this model of development is Test Exchange.

I will describe Test Exchange in a later post.

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.