“Two many cooks: ” — A response article to “Why Pair Programming is the Best Development Practice”

The author of the article “Why Pair programming is the Best Development Practice” attempts to convince us that pair programming is an essential and easy to implement practice and advocates its usage as often as possible.

In my opinion, I agree that pair programming can be excellent tool for generating quality code and encouraging knowledge sharing. But believing it is a panacea for all problems can lead to exasperation and inefficiency.

I refute the article’s extreme stance on pair-programming with experience ininformal settings, working on group assignments, developing games and small programs with colleagues. Experimenting with the practice has shed some light on the subtle frustrations and drawbacks in pair programming and there definitely exists alternate methods to attain the same benefits. 

Pairing doesn’t always result in quality

The author argues that the quality of the work produced by programming pairs is far better than what could have been produced individually. This is true in some cases, to some degree, but not in general.

It’s true that pair programming reduces coding errors and bugs by making mundane tasks more interesting and having another pair of eyes reviewing the code. However, dull and routine coding implies something fundamentally unsavory about the program, complexity and redundancy. Refactoring the code frequently and using TDD (Test Driven Development) at the smallest possible unit, should avoid these problems altogether. I’m definitely a proponent of discussing complex and unwieldy methods with another person; it’s an excellent way to work through the logic and identify the errors. However in many instances both programmers may fail to see the need to restructure the solution and continue to patch up problems as they arise (this is especially true in novice-novice pairs). In fact, in the paired projects I’ve been involved with, the mutual pressure to seem productive made us continually strive for the next milestone to achieve. This usually worked against the quiet consideration needed for effective refactoring, and we were both convinced it was necessary only when the bugs became too difficult to solve.

Nowadays when facing a team project, I opt for planned code review instead of paired programming, where team members are required to review and comment in their own time. Firstly, this gives the members more freedom to be critical when reviewing code away from the group, since it avoids confrontations and arguments. Secondly, feedback is received from a number of people and an agreement can be reached by the whole team and it’s a lot more flexible to your schedule. But most importantly, when faced with criticism I find people are far more eager to explore and experiment with proposed solutions after a review than during a pair programming session.

Becoming dependent on the pair

There is another subtle disadvantage that the article did not address. Pair programming encourages vocalization of ideas and team-work, but as a consequence the individual becomes dependent on the partner and loses some of the skills that define a good programmer.

Far from the overweening confidence that seems to plague conversations with programmers, I believe the actual act of coding requires a modicum of self-doubt, a constant suspicion that what you’re writing could be performed better. Am I doing down the wrong track? Can I refactor now and save trouble later? Should I leave a comment to re-work this algorithm? When programming alone, I’d ask these questions and take time to write down my decisions for later consideration. When I was pairing, these thoughts were naturally replaced with conversations, conversations that were rarely recorded since no one wanted to be the scribe. After about 6 months, I’d lost the internal checking mechanism (i.e. looking like escaped mental patient arguing with myself whilst staring at a screen). Interestingly this effect was also noted in a study by Williams and Kessler[4], where students performed worse individually after pair programming training sessions. Pair programming is successful mainly because it forces immediate accountability for your work, but when this is taken for granted, you begin to lose the ability to be conscious of your own mistakes.

I don’t intend to imply that brooding solitude is the answer, and I agree with the author that team-work and communication is absolutely essential in software projects.  When approached with the right attitude, pair programming is well noted for its effects on bonding co-workers [1]. However, getting a team to integrate can be achieved through alternative methods such as social and casual events in the workplace. Going back to experience, the times when I was most productive weren’t the times when I was paired up. Rather I found that working with a pair was more of a welcome source of distraction and a way to throw around ideas.

Standardization of thinking

After only a few pair programming sessions, you begin to understand the style and thinking of your programming buddy. The article didn’t mention what a boon this is to software companies that aim to standardized practices across their teams. Rather than forcing heavy training presentations and coding manuals on novices, pair programming is thought to be a great way for best practices to dynamically bubble up to the surface and become the standard [4]. Simple things like following the same commenting, segmentation and bracketing styles can lead to hours of saved frustration. However, I believe this standardization also leads to the same way of thinking, which detriments innovation in a project.

For example, it seemed that having to constantly defend an idea against a partner ultimately leads to the one with the stronger personality to win the debate, cutting ideas at the bud. Of course, as the article mentions, this can be avoided if everyone was enthusiastic to try new things and communicates well. But in reality this is rarely the case. Instead, giving a programmer space to develop an idea and time to clearly express its benefits in frequent group / pair discussions, worked far better in my teams.


As the original article identified, pair programming can deliver improvements in program quality and team bonding, but many of these benefits can be replicated with other methods such as code review and social activities rather than invading the creative space of programmers. Furthermore, I find it tends to weaken the innovative idea generation in a project. Therefore, I disagree that pair programming is the best development practice; sure it has its uses but it shouldn’t be prescribed as a panacea for all problems.



[1] Cockburn, A. Williams L. (2000). “The costs and benefits of pair programming.” Extreme programming examined 223-247. <accessed on 6/3/2014 at http://www.cs.pomona.edu/classes/cs121/supp/williams_prpgm.pdf>

[2] Evans J, (2012), “Pair Programming Considered Harmful”, <accessed on 3/3/2014 at http://techcrunch.com/2012/03/03/pair-programming-considered-harmful>

[3] Needham M. (2011) “The disadvantages of 100% pair programming” <accessed on 2/3/2014 at http://www.markhneedham.com/blog/2011/09/06/pair-programming-the-disadvantages-of-100-pairing>

[4] Williams L., Kessler R. (2003) “Pair Programming Illuminated” Pearson Education.