Benefits and Positive Value of Pair Programming

After reading High costs and negative value of pair programming, i just had to write a post about the Benefits and Positive Value of Pair Programming.
Where to start? How about a quick statement to debunk Capers Jones analysis of Pair Programming. Capers uses 4 data tables to statistically prove pair programming invaluable and expensive. The basis for all the data is LOC (lines of code). LOC is a vanity metric, which only serves to document the current state of a product, but offers no insight into how we got here or what to do next. To borrow from Scott Bradley's blog post on Cohort Analysis,

vanity metrics give the “rosiest possible picture” of a startup’s progress, but does not track how people are actually interacting with the application.

That is exactly what LOC are, a vanity metric that offers no insight into what is really happening.So how should we measure the effectiveness of Pair Programming? Great question! Let's discuss Actionable Metrics. Actionable metrics tie specific and repeatable actions to observed results. Agile teams are full of repeatable actions, the smallest being Red Green Refactor up to Iteration Planning and on to Release Planning. During the Red, Green, Refactor cycle a pair is constantly inspecting the code and reacting to it. Capers cites that lone programmers produce 20 LOC/hr, while pairs only produce 15 LOC/hr. That 5 LOC/hr less is a direct result of constantly refactoring and evolving the code. Those 15 lines of code are going to be more maintainable and easier to hand off to another developer than the 20 LOC written by a solo programmer that has not been reviewed by a peer. Not too mention you now have cross pollination and not just one developer can maintain those 15 lines, but now at least 2 developers can reducing your single point of failure.

What other actionable metrics can we observe about pairing? How about delivery of features? It's repeatable and produces a result. Features may differ across teams and projects. Based solely on my experience pairing on large teams at companies like Progressive and Nationwide to small teams at startup companies like Save Love Give, the teams that paired effectively produced features more often and of higher quality with less defects. Those teams also exhibited a higher degree of cohesiveness and shared understanding that allowed them to be more effective in other aspects of the project, not just programming. The teams I have been on that have not paired or utilized what I'd call "partner programming" had to rely lengthy inspection processes and larger QA teams to ensure a higher degree of quality. The non-pairing teams also suffered from the side effects of turnover. Whenever a developer would leave the project, code produced by that developer immediately became more costly to extend and maintain.

Speaking of turnover and changes within a team, one less often mentioned benefit of pairing is easier onboarding of new team members. New team members become contributors day one, unlike non-pairing teams where new members must endure weeks if not months of learning standards, development process, code base, etc. Pairing teams are able to introduce new members to standards, process, code base, etc as they are working "hands on" in the code base.

So why would a team not pair? Culture. A culture that promotes strong egos, limited collaboration, and creates silos will certainly struggle with pairing. In order to pair the team needs to commit to setting their egos aside and working as a team. Even the most senior developer has something to learn from the youngest of developers!

The most difficult thing about writing this post is keeping it focused on solely pairing and ignoring other process changes that typically accompany teams that pair; TDD, iterative development cycles, and continuous integration among other things. Pairing is a process change. Actually it's a social change in your team culture. Your entire team needs to be open to that change. In 2002 I was part of a team that underwent an agile transformation and took on the entire book of eXtreme Programming practices. It took awhile, but the entire team remained open to the change and in the end we delivered some outstanding software ahead of schedule without working crazy hours. It turned out to be a project I frequently refer to when I describe the ideal scenario. We went from changing pairs a 1-2 day basis to multiple times per day as it made sense.

Just because you do not pair does not make you evil. Well not entirely evil :) It just means you have a different preference than I do. I respect your skills, however myself and others have experienced the benefits of pairing and prefer to work on teams that are open to collaboration and pairing as they can deliver much more value in less time.