We pair program a lot at Rally, and I did it a bit before joining Rally. I’d like to share some of the patterns I’ve observed in the way people pair, and offer some suggestions about how to get better at it. This isn’t a talk about pairing setups, because our former colleague Rod covered that pretty well in a recent post of his.
To be clear, this is not based on any sort of industry research or anything like that – it’s just based on my experience. There are a bunch of commonly cited advantages and disadvantages to pair programming, from constant code review, less bugs, and enhanced productivity to tying up two developers for a single developer’s job. Those are all true of all the patterns I describe, but each pattern has its own strengths and weaknesses.
Oh yeah… these are in no particular order.
1 – Distributed Pairing
I did this a lot in my last job. Our work environment wasn’t opposed to pairing, but it also wasn’t set up for it. At best, we could have done the level zero pairing from Rod’s post. Often, I’d take a screenshot of code and paste it into the IM client we used and send it to a colleague across the building or on a different floor. I’d type whatever contextual information was needed, and he’d respond over IM as well.
This is not ideal. You can’t see the same screen or edit the same file. You can only communicate as quickly as you can type and read. Perhaps most importantly, you can’t read the body language of your pair.
2a – Teaching by Pairing (learning the craft)
This is pretty common, especially at Rally. We have a broad range of developer skill levels, from interns to experienced engineers. Pair programming is an excellent way to help developers advance their skills. By helping your pair work through a task, a problem, or an exercise, it’s possible to advance the rate at which your pair learns. It’s an excellent way to teach design, testing, or a new language.
2b – Teaching by Pairing (knowledge transfer)
Sometimes we learn while pairing despite not learning any fundamentally new skills. Knowledge of a new domain isn’t a skill, per se, but it’s an invaluable part of an engineer’s job. Pairing is an excellent way for two developers of any skill level to familiarize one another with a codebase or a project.
3 – Ping Pong Pairing
Ping Pong Pairing is a key part of both 2a and 2b. It’s also an important part of other forms of pairing. For those who don’t know, it involves one member of the pair writing the test and the other writing whatever implementation is required to make the test pass. By alternating between writing tests and writing the implementation, it allows both members of the pair to influence the direction the code takes.
Don’t like the test? Write a crappy implementation. Don’t like the implementation? Write a test that breaks it.
As the name would suggest, Ping Pong Pairing can become a game. Challenge your pair by writing the simplest, stupidest code possible to make the test pass. Make them write good tests and they’ll make you write a good implementation.
4 – Real Distributed Pairing
The remote pairing I described above is lame remote pairing – incomplete remote pairing. It isn’t even really pairing. A better setup for remote pairing involves screen sharing on similarly sized monitors and a good audio connection. As important as anything is that the audio can’t be over monitor speakers and microphones, especially at Rally. Our engineering area is nothing if not noisy. Because your pair isn’t there to see you and body language and because monitor microphones pick up all sorts of ambient noise, it’s especially important to have a headset with a good microphone. Such a headset will isolate what you hear to your pair’s voice, and vice versa.
You should always pair in person when possible, but Real Distributed Pairing is a viable alternative for teams that are distributed either temporarily or permanently.
5a – Story Pairing (short running)
For short-running stories, it makes sense for a single pair to carry the story from start to end. The level of ramp-up needed to bring a new member of the pair up to speed is often more cost than benefit for small stories. Subsequent changes to the same code can benefit from knowledge sharing pairing (2b).
5b – Story Pairing (long running)
For long-running stories, it is often beneficial to have one or two team members involved throughout the life of the story. When I say that, I’m assuming a team of 5 or 6. Having one or two key people who understand the direction a story is heading and who are responsible for driving the story to completion helps keep the story on track. Rotating the other member of the pair regularly helps to distribute knowledge. This is really just a specialization of 2b.
Pairing is a valuable tool in the developer toolbox. Understanding the many ways it can be applied is crucial for realizing all of the potential benefits. In a future post, I’ll talk about some of the ways pairing can become toxic. There are as many Pair Programming Anti-Patterns as there are Patterns.