When doing Test-Driven Development, one of the things we do is called “ping-pong pairing”. So the other developer will write a test, then make it compile but fail. Then he passes the keyboard to me. I implement the feature just enough to make the test pass, then I write another failing test and pass it back.

When the task is done and code is checked in (at least to the local git repo if not the big svn repo), the pair breaks up. Generally tasks only have 2 hour estimates (sometimes less) so you’re only pairing for the two hours. Then you pair up with someone else to work on another task. If a task is taking longer than expected, or the pair “goes dark” (meaning they aren’t talking) then you shuffle the pairings.

Between these tasks, you might go have lunch, or take a break from coding to watch a video on youtube at your desk, or check your RSS reader for a few minutes, or go take a walk, or go downstairs and play some ping pong or foosball. We take breaks often because getting away from the code for a few minutes helps keep a fresh perspective when you come back to the task. Physical activities like walking or playing ping pong help with blood circulation, which helps your brain.

It’s also nice to have an odd number of developers, which we do. This way, one person is working without pairing. Usually this person will work on a defect instead of a story, or they’ll work on a story where everyone understands what needs to be done for that part of the code. If you don’t feel like pairing, you volunteer to be the odd man out for a task.

In an 8 hour day, I’m probably pairing somewhere between 4 and 6 hours. It’s important to have a good setup for it – big monitors, comfy chairs, no corner desks (so that the devs can be side by side at the flat desk with the monitor between them).

I see pairing work so well every day that I consider my dev career prior to Rally to have consisted mostly of wasting time. When I think back to all the code I’ve written for a job, I’m annoyed at how much less efficient I was then since I wasn’t pairing, and how much better my code and my products would have been if I had paired on them full time.

When you have a second person working with you, you find that you try harder to code well. You’re far, far less likely to be willing to apply duct tape to a problem, because someone else is working with you and he or she is more likely to object to the duct tape. If two people approve a hack and implement it, it’s almost certainly because it’s the right approach given the time constraints. If one person sitting alone decides to pursue a hack, it’s far more likely to be a situation where there is a better approach.

Two people attacking a design problem together is far, far easier than one person doing it. Your partner will think of things you don’t, and vice versa. In a non-pairing environment, you can always call someone to a whiteboard to help you work through a design issue, but when you do that you’re only calling for help when you know you need it. The times when you need help and don’t know it go unaddressed – and yet despite the fact that you need help, I guarantee that you’re coding SOMETHING and checking it in. It’s almost certain to be shitty code. The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds.

Pairing also helps a great deal with collective code ownership. I don’t feel like there are any realms of the code that “belong” to any team member. You don’t have a situation where one person is the “expert” on a part of the codebase, since that person worked with someone else when they wrote it, and everyone likely shuffled around while it was developed. EVERYONE has seen that part of the codebase before, which means EVERYONE feels comfortable refactoring or extending it. This enables the team to perform improvements to any part of the code whenever they are working, which leads to technical debt being paid off very quickly. I often find myself shocked at how good the quality of the code is that we write and that we’ve written before. The product is ENORMOUS in code size, easily the biggest I’ve ever worked on, but there are very few areas of code that I would consider bad at all, and all of those are the earliest parts of the code that were written (and were written without pairing or TDD).

Pairing fosters a collective unity that I haven’t seen anywhere else. There are obviously issues (like you mention, when people have burritos for lunch pairing in the afternoon can be a challenge; hygiene can sometimes be a serious issue as well, especially with all the Boulder hippie-types) and challenges, and there’s no denying that you’re producing fewer lines of code per day since only half your team is coding at any one point. I don’t consider that a bad thing, though (if you have two solutions that equally solve a problem, the solution with fewer lines of code is the superior one) because the QUALITY of the code that IS produced is so, so, so much higher.

Like I said, when I leave Rally (which I don’t see happening any time soon) if the next company doesn’t do pair programming, it’s going to be a tough adjustment to me. It would be like walking into a new company and finding out that all of the developers only use vi for everything and refuse to use IDEs. Sure you get the job done, but god damn you’re being inefficient about it. When people hiss at pairing because they can’t listen to headphones or don’t want to sit next to a fat guy, it sounds to my ears EXACTLY like someone complaining about IDEs being too complicated or how great vi is. Programming alone/vi is definitely a good way to get code written, but pairing/intellij is so much more effective that I just shake my head at all the time wasted not utilizing it.

I’ll probably write a more detailed post about pairing someday.

Maybe part of it is because I never wanted to be that close to another fat guy for that much time, particularly if we had lunch at a place that… well… lends itself to flatulence in the afternoon.

You’ve eliminated the ‘fat guy’ concern from your list of reasons not to do it though, so maybe you don’t feel the same way.