The value of Pair Programming

Gary Filer made an interesting comment to me the other day;

“I use to think that the value of pair programming was the shared brain”

“But after seeing you pair for the last week, I realized that the shared part is actually the waste. The value is in the differences”

The Cost of Mistakes
In my talk ‘Introduction to Agile’ I assert that the core principle of agile development is accepting that we will make mistakes, and doing things to

core agile value:

Reduce the cost of mistakes

Being an introduction talk, I only talk about pair programming from a “Knowledge Backup” point of view:

“If one of your employee’s leaves, what happens to your project?” 

But pairing reduces the cost of mistakes constantly.

What Gary was seeing was the countless times Jason or I would say “Let’s do ...” only to have the other one say, “No, your forgetting about...” or “No, there's a better way...”. Each of those times would have resulted in a much more costly mistake that was headed off at the pass.

Of course, another value of the pairing overlap comes from just looking at the mistakes.

For Example: We were doing some cleanup just the other day. Finding dead code and deleting it. Removed about 10,000 lines of useless clutter from the project, which is good. However, I probably had 5-6 times where I went to delete something that was NOT clutter, and Jason stopped me. Likewise Jason had 4-5 times where he went to delete the wrong thing and I stopped him. Together, we didn’t push any of those mistakes back to the main branch when we checked in. This is like a raided disk drive. You don’t double, you square. If I’m right 95% of the time, and Jason is right 95% of the time. Then individually we are wrong 5% of the time. But paired, we are only wrong 0.25% of the Time (5% of 5%)

In today’s world of Ctrl+Z it is sometimes easy to forget that an undo even qualifies as a mistake, the cost is so low. Agile methods endeavor to make all mistakes that cheap.