Ping Pong Pairing

Pair programming is an oft misunderstood beast. "What a waste to have two people do the work of one!" managers say. "I think better when I'm working by myself, with headphones on" exclaim the uninitiated. With this post, I'll explain a technique called Ping Pong Pairing that I find makes for an awesome pairing experience.

There are two roles you can play while pairing, navigating and driving. The driver is the one that is typing on the keyboard. The navigator is the one who isn't. The navigator isn't sitting idle while the driver is going. He is thinking a step ahead. Looking at the code the driver is writing and looking for weaknesses or missing features.

Ping Pong Pairing is a technique where the driver and navigator swap roles once there is a broken test. The process generally goes something like this:

  • Fred writes a failing test
  • Jim writes the code that makes that test pass then writes another failing test
  • Fred makes Jim's test pass and writes another failing test
  • and so on...

This process works best when the roles swap happen as frequently as possible. When a pair has gotten into a good flow, they can be swapping roles every 30 seconds. Think of it as a game of hot potato.

Outside-In testing has been growing in popularity in the Rails community. Outside-In is where you start developing a new feature with a very high-level test using cucumber or a Rails controller test. This can throw a monkey wrench into the rules of Ping Pong because it may be a very long time before the first high-level test passes. So we tweak the rules and allow a role swap if the driver can write a failing test at a lower level in the architecture. Using a login form in Rails as an example, it would go a little something like this:

  • Fred writes a failing controller test that you can login by POSTing a username and password
  • Jim writes a failing test on user that verifies the password
  • Fred creates the User class and makes the verify_password method return true, then writes a test for the inverse case
  • Jim implements the rest of the verify_password method, all the user tests should now pass. He reruns the controller test
  • Fred implements the controller method and writes another test for an error case
  • and so on...

The really great thing about Outside-In is that you know when you are done. Outside-In with Ping Pong is a win. To sum up, the driver types, the navigator thinks ahead. Try to spend as little time driving as possible. A great game can be made by getting one of these and making the one who drove the most buy the first round.

blog comments powered by Disqus