Friday, April 18, 2008

When to use Pair Programming

Several years ago right about when Extreme Programming (XP) became popular, one of the developers on a team I was managing wanted to give pair programming a try. He paired up with another programmer and went to work on some of our more complicated algorithms. I can't tell you today whether that pair produced better quality code or if they were more productive, but they certainly felt proud of their achievements. So much so that they tried to influence other team members to give it a shot.

That didn't work over so well. The other developers in the group didn't want to pair up and some claimed that it created an uncomfortable working environment.

Today pair programming is a bit more accepted and understood, but I'm still not convinced it provides value in all development tasks and for all teams. I think pair programming is very appropriate when bringing new team members into a group as a form of training. It may also be useful in complex refactoring exercises, programming efforts that require significant object oriented designs, or development work on algorithms or procedures that have performance considerations. I'm sure there are many other tasks where there is a strong argument for pair programming.

But there is a danger if a team adopts it as a standard, default practice. In every development cycle, there comes a point where the team is challenged to take on more tasks either to meet a deadline, react to market conditions, or handle risks. At that point, the team may be challenged to break pairs in order to take on more work.

I know what some of you are saying. Breaking pairs doesn't necessarily mean more tasks can be completed, and there is a risk that breaking pairs will reduce code quality or create more defects.

That said, I think a healthier approach is to budget for pair programming. Consider the following approach:

1. Given an iteration, one pairing team is established, what critical tasks would be assigned to that team?
2. Then look at the remaining tasks and decide which of them could be addressed using a single developer and introduce the least risk. Assign these tasks to individual developers.
3. Repeat this exercise until all tasks are assigned.
4. Look at tasks assigned to individual developers (non-pairs) and evaluate the aggregate risk. Consider other options to derisk including code reviews and additional testing.
5. After the iteration completes, the team should reflect on overall quality. Tasks where pair programming was applied, determine what benefits were realized. Quantify (or at least qualify) these benefits. For single developer tasks, quantify/qualify risks realized. Catalog this reflection.
6. Consolidate (5) into lessons learned. Apply these lessons to subsequent iterations.

By following this approach, a team can formulate a more scientific and defendable position on when to apply pair programming.

1 comment:

  1. I completely agree with you. I really like this article. It contains a lot of useful information. I can set up my new idea from this post. It gives in depth information. Thanks for this valuable information.
    Web development Company

    ReplyDelete

Share