Why do we Pair Program?

One of the most controversial agile practices has to be Pair Programming. Matt Wynne has a blog post that lists several personae and why they don't want to pair program. It's a preview of what he presented at Agile 2009.

Other people have written about the benefits of successful pair programming, which is an after-the-fact analysis. Right now I'm going to look at why we pair program, which is about intention

I recently started thinking about why we pair program. What is our intention in using this practice? I came to the conclusion that Pair Programming promotes many of the Seven Skill Pillars named by the Agile Skills Project.

Pillar: Collaboration
Pair programming is specifically listed as a skill of the Collaboration pillar, but it also supports Collective Ownership by preventing silos of knowledge (technical or domain knowledge) from forming.

Pillar: Technical Excellence
Working directly with another developer reinforces good development practices, and two sets of eyes on code lets fewer mistakes make their way into the product.

Pillar: Self Improvement
Pair programming sets a tone for a culture of continuous learning by creating ongoing opportunities for co-mentoring.

Pillar: Supportive Culture
The transparency around each developer's skill level that comes from programming in front of each other gives a developer an opportunity to be tolerant and encouraging, knowing they will receive the same treatment in return.

Pillar: Confidence
By supporting each other in the practices of Continous Integration and Test-Driven Design, and by having a design and implementation that is jointly created, a pair can know they are producing quality code.