Sam Newman's site, a Consultant at ThoughtWorks

Image from Flickr user Findo, licenced under the creative commons. Original URL: of the struggles people can have when they first start pairing, is understanding when it is time to drive, and when it is time to watch. Developing a good tempo to the act of pairing – and understanding when the change over should occur – can make it seem like a much more fluid activity. When it is working well, outsiders will see the keyboard moving backwards and forwards between the pairs (albeit perhaps slightly slower than a game of table tennis!).

If one pair member hogs the keyboard too much, the other member can feel that they are not properly involved with development. Depending on your development tools and build times, you may need to identify different points at which to pass control. The important thing is to ensure that both members of the pair get to feel equally involved in the development. Set yourselves a target for the maximum duration for each member to have control of the keyboard – ten minutes seems a good target to aim for, but a shorter duration may work better for you.

Example – Test, Implement, Refactor, Switch

When using Test Driven Development, a good way to develop this tempo is to use the acts of writing a test and making it pass to define when to change over. I’ve seen success in having the person A write the test, then have person B get the test to pass and refactor, then write the next test before passing the keyboard back to person A.

Extreme Example – Chess Clocks

Sourced from flickr user SooYoung, under creative commons. Original URL: example was related to me by a colleague. The team in question had chess clocks at each pairing station. The idea was that each member of the pair got to drive for four hours of the eight hour day. To keep track, at each switchover they’d click the chess clocks to start the other persons timer. If at the end of the day if you’d used up all your time, you had to watch. Very quickly each pair worked out a dynamic in which the time became equally distributed – I’d certainly of liked some video footage though!

10 Responses to “Pairing Pattern: Ping Pong Pairing”

  1. sam

    Pairing isn’t about sharing typing duties – it’s about having a continuous dialogue between developers that can help share ideas, ensure good code gets written and keeps people focused. Those benefits mean that we can actually solve problems faster working together, than when working alone.

  2. Nicholas Blumhardt

    Interesting to see the comments about pairing and debugging. I’ve found that pair debugging sessions are extremely efficient, perhaps because the initial set of possible solutions is larger, while dead-ends are eliminated more quickly.


Leave a Reply to sam Cancel reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Basic HTML is allowed. Your email address will not be published.

Subscribe to this comment feed via RSS

%d bloggers like this: