Home > Blogs > Pair Everything, To a Point

Pair Everything, To a Point

Pair programming is one of the agile practices that has most polarized people on both sides of the fence: sitting two people down at the same screen and keyboard to develop a piece of code. Having experienced this practice over 25 years ago and finding it to be extremely productive, I'm in favor of it being applied more than it is now. In fact, I would advocate pairing up (or more) for almost any practice we apply in the process of building our products.

For those that don't see the value in pair programming, the argument centers around the obvious doubling of cost of resources to develop the same component of the product: how could this doubling of cost be recovered in terms of productivity or quality? In many cases, this doubling of cost is more than recovered when we take into account all the dimensions of value we are gaining.

For difficult challenges, adding a second set of eyes can provide the different perspective required to arrive at a more elegant solution. Pairing up essentially provides instantaneous and ongoing peer review, which is acknowledged as one of the most valuable techniques we can apply to improve product quality. Working together to solve a problem improves the relationship between team members, increases common understanding, and reduces risk of deep issues cropping up later in the lifecycle. If the pair working together are the producer and consumer of that artifact, we eliminate the notion of 'throwing it over the wall', and the corresponding high risk of having it thrown back when it doesn't serve its purpose - and the diminished relationship that results.

Teaming up is not a panacea, it is another tool we can wield to solve a problem, a different way of allocating resources that generates different results, and can more effectively solve some of the challenges on your project. When there is a particularly difficult challenge, or a particularly critical component to be developed, or simply an opportunity to teach or share information among the team, getting the right people together to solve the problem can provide enormous value. Be reasonable, though: don't dogmatically assign the same two people to work together all the time, or even assume that everything has to be done in pairs. As a family it makes sense to agree on where we are headed on our vacation, but it only takes one of us to take out the trash.

All of these arguments for collaborating as we develop a piece of our product (or we make critical decisions), extend beyond the development of code into anything else we produce. Indeed, my experience with other product artifacts provides more examples of the value of getting together to solve problems.

It can be easy as an individual to complete a template for any piece of information, such as a vision statement. I have found, though, that when different people on the team complete that vision statement independently, there will be significant differences in the results. Far better to get the different stakeholders together to build a shared understanding, to appreciate each others' perspectives, and develop a solution that meets everyone's needs right up front.

Indeed, I would suggest that the industry as a whole needs to move more towards collaborative development at all levels, rather than dividing up the problem, each person building their part, then finding that most of the parts don't fit together when integration starts. If we were to sum up the costs of all these collisions, including the cost of repair and the cost to the relationships, pairing up to get a solution that works the first time for everyone makes way too much sense.