Pair Programming Observations


resister must initiate Fagan inspections or some other sort of formal review. One way or another, the code must be reviewed--otherwise you'll get pricy consultants (like myself) or unguided novices, producing unmaintainable garbage. Often, people find that the evil of pairing is preferable to the evil of group review.

Ultimately the rules should be up to the team, as long as the rules satisfy the requirement that code is reviewed. If the entire team revolts and insists upon no pairing, then they can all do inspections or whatever review form acts as a second-best choice. If 95% of the team insists upon pairing, and the sole remaining developer can't deal with it at all, the organization should help them find something else to work on.

While this may sound intolerant, remember that software development is a team effort. Suppose I go to your shop and find out that you value RAD. You sit in a board room with 25 other people for two days and hash out every detail of the project. You then produce 200 pages of design documents. But I have a personality disorder that prevents me from contributing in such an environment. I can't stand sitting in a room for days on end slogging through stuff, 95% of which is useless to my role. And I also have a disorder that prevents me from understanding design document doublespeak.

Do I belong in this organization? Probably not. If the organization is successful with this culture, why should they waste time and money trying to accommodate my obstinance?

I'm not trying to be clever or obtuse here. The point is that organizations should grow the cultures that they value, and that those cultures may not be appropriate for everyone. Anyone who says every shop should do XP or RUP or whatever is insane. The reality is that there are always other shops to choose from.

Other Pairing Benefits
The book Pair Programming Illuminated goes into much further depth on the costs and benefits of pair programming, in addition to many other related topics. I highly recommend it. Over the years, I've built my own brief list of pairing benefits.

General benefits:

  • Produces better code coverage. By switching pairs, developers understand more of the system. Many benefits can result from this increased knowledge.
  • Minimizes dependencies upon personnel. Everyone worries less about buses and trucks.
  • Results in a more evenly paced, sustainable development rhythm.
  • Can produce solutions more rapidly.
  • Moves all team members to a higher level of skills and system understanding.
  • Helps build a true team.

Specific benefits from a management standpoint:

  • Reduces risk
  • Shorter learning curve for new hires
  • Can be used as interviewing criteria ("can we work with this guy?")
  • Problems are far less hidden
  • Helps ensure adherence to standards
  • Cross-pollination/resource fluidity. Allows you to swap members from two or more teams on occasion, with minimal downtime. Usually each person will bring immediate value to the new team ("you guys should use this utility class that we built here...").

Specific benefits from an employee perspective:

  • Awareness of other parts of the system
  • Resume building
  • Decreases time spent in review meetings
  • Continuous education. As someone who thinks he is a pretty hot programmer, I still learn new things every day from even the most junior programmers.
  • Provides the ability to move between teams. ("this team is boring," "I can't stand working with him," "that stuff they're doing looks cool."). Since this can be a benefit for management as well, they don't have to clamp down on their resources.
  • More rapid learning as a new hire. You don't sit and

About the author

StickyMinds is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.