Pair programming really needs to be experienced to be fully appreciated. Just a few years ago, I loved my single office and I was completely against the idea of spending all my time programming with somebody else sitting at the same computer. Today I advocated using pair programming at work and I gladly gave up my office to work in a pair-programming lab alongside the whole team. Funny how things change.

For the last few months we’ve been doing pair programming at work. And not just pair programming, but full extreme programming with test-driven development, continuous integration, collective code ownership, customer-driven stories, team co-location, etc. It has been a fascinating experience and it has been working out better than I even imagined.

I felt that all the extreme programming books I had read just touched on the subject but were light on the specifics. What’s more, it’s one thing to read about it, and something completely different to actually do it. Once we started doing it, there were some very basic questions that immediately popped up: What do we do with an odd number of people? How often should we rotate pairs? How are pairs formed? How often should we be switching drivers? Is it normal to be exhausted after several hours of pairing? etc, etc, etc. With questions like that in mind, I decided to pick up a copy of Pair Programing Illuminated. I was hoping it would provide me with the tips and experience of veteran pair-programmers and jump-start our experience.

Unfortunately, it failed in that respect.

Pair programming really needs to be experienced to be fully appreciated. Just a few years ago, I loved my single office and I was completely against the idea of spending all my time programming with somebody else sitting at the same computer. Today I advocated using pair programming at work and I gladly gave up my office to work in a pair-programming lab alongside the whole team. Funny how things change.

First I started to warm up to the idea by observing how useful it was to sit down with someone and work with them on a piece of code, either debugging it or working through the initial design. Then it finally hit me when I realized that most of the problems that we have as programmers are not due to lack of skill or technology, but rather to lack of communication. Two programmers who communicate well and work very closely with each other will get a lot further than two people who shut themselves in their office, refuse to talk, and are hostile about anybody touching their code. When you only have a couple of people, it might not matter. But as teams grow and we have eight, ten, or more programmers, then communication becomes a much bigger issue.

But pair programming goes much further then just increased communication. It spreads knowledge through the team like wildfire. And that knowledge is not just of the code you’re writing, but also programming languages, design approaches, standards, tools, debugging techniques, etc.

Pair programming is also a key step towards having collective code ownership: code that everybody feels is his or her own and is willing to modify whenever it’s necessary. I’ve said it many times and I’ll say it again: the quality of a code base is directly related to how easy it is to modify. The more people feel that they know what’s going on, the more willing they will be to modify it whenever it’s necessary (and it’s much better to modify it in small steps than to take a huge hit and try to do a huge modification at once). The main ingredient of a healthy, easily modifiable codebase is unit tests, but that’s a whole other story.

Another consequence of pair programming is the reduction of sloppy or bizarre or just plain wrong code. It’s a lot harder for horrible code to happen when two people are at the computer writing something. Whenever the driver starts getting lazy and writing sloppy code, the other person immediately asks “What the hell are you doing? Shouldn’t we be doing this instead?” That’s usually enough to spur the driver into doing the right thing. Otherwise, he can always pass that keyboard and say “Fine, you do it.” I’ve been on both the giving and the receiving end of that situation, and it really works. In the end, you end up with a much better code base.

Finally, a consequence of pair programming that should not be underestimated is that it really fosters team spirit. Sometimes it’s hard to see that we’re all in the same team working towards the same goal. Extreme programming helps a lot in this regard, but pair programming helps a huge amount to get close and personal with your teammates and get to know them a lot better.

All right, going back to the book, where does it fit in? It has a fairly narrow focus, but somehow it tries to appeal to many people. In the introduction, they claim they are targeting developers who are thinking of trying pair programming (or convincing their bosses to do so), developers currently doing it, managers, QA, and even educators! I’m afraid that they over-reached a bit and spread themselves too thin on the ground.

The book is divided in four parts:

Part 1: Benefits of pair programming and how to sell it to your bosses and organization. This is the best-developed part, and this is where the strength of the book really is. Unfortunately, that’s not what I was looking for since we had already sold the idea of pair programming, but it could be useful for people hoping to roll it out in their organizations.

Of most interest are the studies that make a business case for pair programming and show how it really is not a wasteful use of resources. Just recently I was telling a friend how I was doing pair programming at work and his first comment was “Wow! I can’t imagine us doing that for budget/time-constraint reasons, but that sounds interesting.” But the whole point of pair programming is that it’s supposed to be better in the long run (and “long run” can be as short as a few months, and certainly less than one project cycle). This part will give you ammunition to debate this point.

Part 2: Getting started. This is what I really wanted to read a whole book about. It covers some things like the work environment and pair rotation. Unfortunately, it’s way too short and elementary. It covers a few of the basics and quickly moves on. This leaves the door wide open for another book on pair programming. If anybody knows of one that covers this topic, let me know.

Part 3: Tips and tricks. This section is completely forgettable. The book spends almost 100 pages (out of a slim total 260 pages) discussing different pair personalities: introvert-extrovert, introvert-introvert, gender and race issues, etc. Frankly, I didn’t get a single thing out of this section, which is very disappointing.

Parts 4 and 5: Miscellaneous stuff and case studies. I guess the book had to be bulked up a bit more, so it dedicates a chapter to extreme programming (go read Extreme Programming Explained instead) and another to Collaborative Software Process. Not much else of interest here either.

Given the lack of literature in pair programming, the book is definitely worth a quick read if you’re thinking of rolling out pair programming in your company. Part 1 will give you some good arguments to discuss with your managers and ease their fears. Otherwise, if you’re already doing pair programming there really isn’t much of value. It’s maybe worth a quick leafing through, but that’s about it.

In any case, if you haven’t tried pair programming, I really encourage you to give it a try. You don’t need to make it a sanctioned activity in your company. As long as you have somebody else willing to try it, you can both try the experiment of doing pair programming with each other working on both your tasks. You might be surprised that you manage to do both sets of tasks in the same amount of time it would have taken before, but with better quality, and, most importantly, you had a really good time in the process.