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.

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.

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.