As mentioned in previous posts, pair programming benefits teamwork, cross-training efforts, code reviews, and social well-being.  Today I want to talk about "the bottom line."  Pair programming is one of the agile practices that actually had the benefit of having formal studies performed to back it up.  I won’t go into those studies in this post.  You can look those up elsewhere.  I would like to focus on what I have discovered from personal experience.

One way that pair programming increases the value of software is by providing a thorough code-review process that is easy to implement without a high degree of special training.  Because the method is so practical, it is likely that code reviews will be done and that errors will be caught frequently so that they don’t make it into the code base.  Pair programming puts every team member in a position in which they can personally find and remove defects immediately.  Less defects means less money spent on expensive support issues. This seems to really work in practice.

Another way that pair programming increases software value is by enabling a programmer to get immediate feedback from a peer as to the readability of the code itself.  As Steve McConnell writes, most of the lifetime of a piece of code will be spent in maintenance.  This means that for a very large part of the code’s life, other programmers will have to understand what the code is doing.  The ability to change that code depends on its readability.  Because another programmer is reading the code as it is being developed, the code produced gets an immediate readability upgrade before it even gets released.  If a piece of code is more readable, it translates into less time spent in maintenance, which means less time spent paying for programmers to fix, update, or replace an old system. I have found that code produced by pairs is easier to read.  Other eXtreme programming practices also help, however.

Pair programming increases the speed at which software gets delivered.  Because it so effectively uses teamwork, you can expect that code will get done sooner.  This happens for several reasons:

• You have more brain power working on the problem
• You say focused longer
• You solve difficult problems sooner

I have personally experienced these things as well.  This can add up to a significant advantage in the end.