The Pros and Cons of Pair Programming

Pair Programming is one of the most controversial agile practices and is considered part of Extreme Programming methodology, initially promoted by Ken Beck back in the 90's.

By definition, Pair Programming consists of two programmers sitting side-by-side working on a given task. While one is coding, the other is observing, suggests improvements, notices mistakes,  looking up the documentation, in general assisting his/her pair in any way in order to complete the task. Both programmers take turns undertaking each of the two roles.

The practice is considered controversial due to its number of pros and cons. It has very strong advantages but also it exposes the project to some very important risks that should be carefully mitigated. 

What are the pros then? Here are some, but each experience of applying this practice can reveal many others: The cons are mostly related notwith the practice per-se, but with the people involved and their behavior.

          - you always have two people knowing the inner working of a feature. So, if one is not around or leaves the team, you have a back-up;

          - two perspectives on the same subject: when you’re stuck in particularly nasty patch of code, trying hard to work your way through, having a fresh point of view can come in very handy. The other one can see better the solution which is no longer obvious to you as you are too involved in the implementation;

        - silly mistakes are quickly caught: Simple mistakes such as syntax errors or repeated variable names can be easily caught and fixed right then and there. This might not seem like much, but it can cut down debug time later and prevent small irritating bugs

          - new team members can be more quickly integrated as they can immediately work on new features by pairing with more experienced developers. Knowledge spreads fast.

           - debugging sessions; this is one of the most common uses of this practice. Whenever one gets stuck and can't make sense of what's going can ask another fellow developer to join and together they are usually able to figure out the issue relatively
quickly. The act of explaining what's going on (often referred to as "rubber ducking") is sometimes all it takes.

The cons are mostly related not with the practice per-se, but with the people involved and their behavior.

          - the amount of interaction that is required by this practice interferes with people personalities or programming style. Programming has been taught and practiced as a solitary activity. Many developers are used to work alone, to focus on the task at hand and their flow is disrupted by the constant interaction. Also they prefer to work at unconventional hours or from home and today's flexible work environment, this is possible, which makes very difficult to pair. The original extreme programming called for a 40 hour work week in which everybody will arrive and leave at the same time.

          - While the technique does not restrict on how to pair developers, and actually is recommended to change pairs often, some senior developers might feel they are slow down by their more junior pair. This will induce them a feeling of frustration that they are doing all the work and tutoring the other on the same time.

        - Not actually getting the work done: for some people pair programming sessions can easily generate in socializing sessions. There are some people who don’t work when there is someone next to them examining their work, these people will not benefit much either.

        - The interaction might not always be positive. Time might be spent more on arguing on different solutions (which might be both correct) than actually doing the work. This is a potential time-consuming scenario with significant impact on the software development.

It is clear that, in terms of resources consumed, pair programming generates an increase in the project budget. Two programmers (which in general are scarce and also quite expensive resources) sitting together all day working on the same code is not something that some managers are seeing as a positive thing. Even though the experience has shown that the increase in development effort is compensated by improved design quality, number of defects reduced, staffing risk reduced (remember you always have a back-up), enhancements of the technical skills (pairing junior developers with more senior ones), improved team communication.

But the adoption of this practice have to be considered very carefully due to the risks related to the cons of this practice. This makes it more controversial and therefore not as wide spread as other agile practices (not part of the agile mainstream practices).

Looking to learn more about Agile practices? 
Check out our available session and catch the early bird advantages!