Ping Pong Programming - No Pairing

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.

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