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.
You should do some more articles on your experiences with pair programming, and what you found works etc.
This is very interesting but not all that new outside the software industry. When I worked in the hardware end of things there was a much higher degree of collaboration. In software it seems one is expected to work largely isolated from other engineers. It is weird that software groups put up with, and in deed foster, so much strange behavior. It is not unusual to have a few people in a group who completely isolate themselves in their offices, and other than some email you never see them more than a few times during the week. When these people leave the group you end up with a code base section that no one wants to touch because it is uncommented, unreviewed, unknown, and scary.
But I remember the joy of working very closely with a small team. When hitting on all cylinders it can be extremely productive.
We tried to create a more collaborative atmosphere in the last two groups I worked in. In one we met with almost total resistance from developers and failed to gain any ground. In the other we were pretty successful with everyone making an effort to review and work in other parts of the code base. However, we didn’t go nearly as far as outlined in this article. I am very interested to hear how this goes over time.
Have you tried code reviews before deciding on pair programming?
I haven’t tried either, but I’ve heard very good things about code reviews, and it seems to me that you’d get similar benefits to pair programming (increased communication, spreading knowledge, better code overall…), at a fraction of the “cost”.
Did you run into “people” issues when you switched to pair programming? From my experience, not everybody like to interact closely with everybody else, or at least, not every day.
Dom,
We used to do code reviews before every check in. That was better than nothing, but I really like pair programming a lot more.
Code reviews are done after the fact. They’re OK at catching horrible things from making it into the codebase, but not about ensuring the right code gets there. With pair programming, both people (or more if you rotate pairs frequently) are involved in the design and implementation of the code. People are also a lot more involved in a pair-programming session than in a code review session.
The claim though, is that pair programming doesn’t have to “cost” anymore, and it’s more cost effective in the long run. I suppose that’s only true if you’re working on a codebase that you care to keep high quality for a few years. If you’re writing one-off game code, there might not be any benefit from pairing.
As for people issues, so far everybody in the team has been doing pair programming without any problems. I would hope that if someone didn’t usually interact closely with other people, he would get over it. We are developing a game as a team after all, not as a collection of invidual achievements. I didn’t think I would have liked it a few years ago, but now I absolutely love it.