< Back

Why Paired Programming?


Posted by Lawrence Sinclair on 20 Jul 2010 at 20:18

It is very important for us to not compromise on paired programming.

eXtreme Programming, or XP, (especially at East Agile) is an engineering process designed to create a consistent, reliable, scalable and low risk software development environment that reduces risks especially in already unstructured, uncertain and risky business ventures. Not doing full paired programming can introduce the potential to complete a project faster, but also introduces a very significant risk of catastrophic failure. We never choose to make the speed in exchange for substantially increased risk.

That is not to stay that we must pair program 100% of the time. There will be times when it makes sense for a team to split their focus or for individuals to work alone. Examples of this include (1) reading and researching, (2) chores such as system configuration, (3) simple bug fixes in deployed systems, or (4) one member of the pair is away for a brief unrelated purpose. The important difference is that the team comes back together and works as a pair on primary development. At this point their separate experience and learning becomes fused together into a common understanding related to the project at hand. 

Kent Beck

Kent Beck
Early Paired Programming AdvocateKent Beck

If developers work independently on separate parts of an application on a continuous basis, even if they happen to be sitting at the same desk when they do that, then very important problems from solo-programming start to emerge.  (1) To the degree that each thread of work is separate, it happens without continuous code review. (2) The same is true about collaboration. Even occasional collaboration on these matters becomes less effective and less insightful because the other person has not built up the mental map of the code base that comes from being involved in the full development process.

And (3) if a developer is sick, quits, or gets fired, there will emerge large gaps in understanding of the code base and large sets of knowledge that are missing from the remaining team. Turnover can simply not be avoided; it happens everywhere. Indeed, the original developer does not even have to leave; that person could be engaged in another more urgent project, or involved in another completely unrelated role in another part of the company. Furthermore, programmers often assert that they would find it easier (or prefer) to rewrite entire applications rather than reverse engineer or try to figure out code that they did not write themselves. Not working in a pair on all major aspects of a project introduces big blocks of risk (bad things that could happen unpredictably at any time, and often at the worst possible time) versus the alternative of potentially slower development that is nonetheless much more predictable and dependable.

As an example, consider that earlier this year we spent about a month developing an application for a client with a single pair of developers. During the course of that month, we had two developers leave the project for various reasons. In the end, four programmers worked on the project, and only one was around for the entire duration. However, development hardly slowed despite the disruptions. We completed the project on schedule. The client noticed no interruptions or problems. And when the client came back to us to do more work a couple months later, we still had someone around who had worked on the entire project. This would not have happened without paired programming.

I would assert that if people are not working productively in a paired programming environment, that the problem is not paired programming. (1) Some people do not work well with other people. They may need to find a company that either deliberately or unwittingly is willing to let them work alone creating applications that are poorly understood by others and that have a high risk of never being completed or of being abandoned because the original developer has moved on. I would also suggest that people who do not work well with others might also have a higher likelihood of moving on, even halfway through a project. (2) Sometimes the problem is that developers are not paired properly with people at their same level. A very fast developer will find it hard to work with a slow developer. And a junior developer will have a hard time adding value to a senior developer. Sometimes a person who is unfamiliar with the programming language, environment, or application will have a hard time making contributions (although this pairing can be an excellent way to bring an otherwise productive person up to speed). And (3) there will be exceptional people and circumstances where someone working alone gets more done just as reliably and maintainably as a pair. But there are fewer people who are this exceptional than there are people who think they are this exceptional. Firms and projects take a risk when they decide that someone does not need to pair program because they are exceptional in this regard.

Leave a comment