Distributed pair programming at Assembla

Posted by Andy Singleton on Thu, Mar 24, 2011 @ 09:00 PM

I have never been a fan of pair programming. Two grown men huddled over one keyboard are sort of like girls who go to the bathroom in pairs. What are they doing in there? They don't share a stall. That would be too slow. If your programmers are good, gossiping in pairs just takes away the bursts of individual intensity that great coders deliver.

Plus, our developers are in different places, which is the reality of modern work.

So, how did we end up working in pairs on the current Assembla release?

It started when we decided to try Gerrit code review as a way of scaling our team. Realistically, people aren't going to do code review unless you force them. Gerrit is particularly rigid. Your code doesn't go in until it gets two votes.

This created some serious bottlenecks. At one point the list of "changes" for review held more than 26 changes that had been rejected, with big nasty red X marks on them, and one with a happy green upvote. On a healthy list, there would be fewer waiting, and a lot more green.

We diagnosed a couple of problems.

Reviewers were being over-enthusiastic about enforcing minor points of style. They were rejecting almost everything. Why not just fix these cases? We needed to reorient them to fix a problem if it was small and they knew how to fix it.
Developers were in multiple time zones, and it was taking a long time to get reviews, and a long time to respond to them.

We though we could fix both of these problems with pairs, and it worked. Our pairs don't actually watch the same screen or share the same bathroom stall. The pair is simply an arrangement to review each other's code, and to discuss it. When you work with a partner:

You work on the same basic feature, and you both understand it.
You make it a first priority to review committed code.
You fix your partner's code if you can.

This lightweight pairing really works in our distributed team. I think that enforcing code review is the thing that makes it work. Pairing, actually, is not important. You can have three or even four people in a review group.

We got a knowledge sharing benefit. Bosses often support pair programming as a way to train new people, share knowledge, and make sure there are no problems if a key developer is not available. Our pair partners are getting trained up on many specialized parts of the system.

We got a productivity benefit. Reviews and pair communication take time. They make the team slower. I'm not convinced that pairing and reviews magically reduce total time because of added quality. Extra work is extra work. However, I have noticed that the team is moving faster, and I think I know why. They are working more. Shhh... don't tell them I noticed. They are working more because they like working with pair partners, and being able to talk about their work.

Code review was an experiment to set us up to bring in more people, and enforce some uniformity in code quality, style, and tests. There are various ways to do code review. Most simply, you can make it a policy that changesets get reviewed and commented with our upcoming simple code commenting feature. I'll post on that next week.

Tags: agile, development process, distributed development, git/gerrit

COMMENTS

One thing that works out with these "style nits" comments is to implement a lint checker right before you upload your change list to Gerrit. That will eliminate 90% of the comments because your linter will spit out the warnings. (Of course you can bypass it by including some extra command line option).

Pairs is like "groups" in Review Board. It works great in some situations, but if your code base evolves quickly, that part of the code could involve the whole team. A good approach in my opinion is to introduce a concept of "OWNERS" file. That file would contain a list of users that own a specific folder. You can have multiple of them. When you commit a file and submit it for review, it will get all the users from the OWNERS file (recursively) and add them as CC for the review. That works great because people can "watch" their code and comment on stuff that they like per folder/package level.

That is how we do it in Chromium, since there are hundreds of developers and millions of lines of code, its hard to maintain groups that way, it was better to place a bunch of OWNERS files in the source code that devs can create and when someone submits a review it will notify them. They can add/remove themselves as they please.

posted @ Thursday, March 24, 2011 10:56 PM by Mohamed Mansour

Comments have been closed for this article.