Benefits of Pair Programming
This post is in response to a blog entry at beyondng.com entitled "How much pair programming is cost justified".
Well, if we assume the perfect development environment with all top-notch developers, then yes, I agree Pair Programming probably has a low ROI.
For the rest of the world though, the following benefits to me show a ROI in short and long term. The benefits are:
1)Two pairs of eyes on the code. Yes, I understand that a pair of terrible coders will still produce terrible code. This also isn't an excuse to not do code reviews with the team. To me team code reviews should be coarse grain dealing more with design/functionality than syntax details. This is where the extra eyes on the code comes in handy.
2)Increases involvement. That is, as a single programmer, there are times where you are either way off task or just plain stumped. By having your pair with you it is more difficult to go surf to digg or slashdot. Thus your personal daily involvement with doing work increases.
3)Rapid learning. Pairing should allow a more open communication between people of different skill levels. Because of the increased involvement each person is more acceptable to learning new things. When the mind is focused and engaged learning is much quicker.
4)Higher actual time vs ideal time. A single coders actual coding time per day is not eight hours. It is more along the lines of 2-4 per day. This is due to the numerous other tasks that we handle along with whatever meetings we attend. By pairing up, each of the coders are committing to a chunk of time to work. I find it harder to interrupt two people working hard on a problem than a single person. Thus the actual time doing productive work goes up when pairing.
I'll finish up with stating that pairing is NOT for everyone. It isn't that they don't see the benefits; it is that they just don't like doing it. To me this is fine. In no way should it ever be forced upon a team. I would much rather a full team try it out and buy into it than have one person shove this technique down the team's throat. However....I also think that everyone should give it at least a couple of weeks when trying it out. One day or a couple hours isn't enough for a test run.
Posted at 09:22AM Aug 23, 2006 by Aaron in Agile |




