I certainly understand that knowledge workers such as programmers need concentration time. I just don’t believe (any more) that programming should be considered to be a solitary activity. Sure, we all need time to gets things clear in our own heads, and sometimes the best way to accomplish this is with a little quiet time. There are other times, however, when it is faster more productive to work with others.
I’m sure that you’ve had the same experience that I’ve had in working through a difficult problem, where the ability to talk through a problem with someone else, to share perspectives and bounce ideas off of one another yielded a much better outcome. And there are those times when the act of verbalizing a problem is all that you need to generate that little spark of insight. All in all, I’ve had plenty of times where I’ve been grateful that others were willing to collaborate with me in dealing with complex problems.
And that is what pair programming brings to the table. And it’s also why a manager shouldn’t walk around worried that he or she is losing productivity because programmers – or testers automating test code – are paired up. Knowledge workers aren’t a part of a typing pool. They are engaging their collective intellect on solving difficult problems.
What is the practice of pair programming? The classic definition of pair programming involves two programmers collaborating at one computer to develop software, using two distinct roles:
The Driver: The programmer who is actively writing code by typing it into the computer. The driver is tactically focused on the current code.
The Navigator: The programmer who observes the work of the driver, making notes on how to improve the code, considering what to work on next, or how the current code fits into the overall design.
Using this model the driver is free to work exclusively on creating rigorous code without worrying about the big picture, and the navigator is free to consider strategic issues without worrying about the immediate code that is being produced. A conversation precedes any driving and helps to synchronize the pair on the direction that the code as a whole is taking.
In practice, a more common approach is a highly collaborative session where two programmers are dealing with design and coding interchangeably. Programmers take turns at the keyboard, swapping roles, working closely together and talking the whole time. (Wray, 2010) I’ve seen this approach used much more often than the classic definition.
What if you have a manager who still dislikes pair programming because they can’t get past seeing two people doing the work of one? In that case, don’t call it pair programming. Call it a “meeting.” People of this ilk typically don’t think twice about filling up a day with business meetings and demanding that all of the real work still be accomplished, so stick to what they’re comfortable with.
What we’re looking for with pair programming is clear thinking to solve the problem at hand, and we want that clear thinking represented in well-designed, clean code. The design and expression of the code should allow for others to easily add to modify or add to it later.
In fact, part of what may be going on with pair programming is a discussion about how the code should be refactored – another good technical practice – in order to make room for a new feature being added. Instead of shoe-horning a new feature into the existing code and making the code more complex and more difficult to update in the future, good programmers who are given the time to properly manage the code base are striving to keep the code base clean through refactoring.
Note that I qualified the statement above with “given the time.” We can’t be agile in the future if the code base is allowed to become difficult and unwieldy because we are rushing to add new features today. Pair programming is one step that we need to take to support one of the principles of the Agile Manifesto: “Continuous attention to technical excellence and good design enhances agility.”
The key benefits of pair programming can be summarized as follows:
- To maintain or improve the overall quality of the code. This includes the design of the code as well as preventing defects from finding their way into the code in the first place.
- To increase productivity by reducing the time it takes to implement complex features.
- To broaden the understanding of the code base, helping to move towards collective code ownership.
Pair programming provides programmers with feedback in real-time. This is the shortest feedback loop possible! With pair programming there is no need to schedule and wait for design and code reviews, they are done in the moment, without delay. Yes, there is an up-front cost that comes with pairing, but one study pegged this to be about a fifteen percent increase in development costs – with the corresponding reduction in defects more than offsetting this investment. (Cockburn & Williams, 2000)
Building on the productivity theme, another study found that pairs could complete complex assignments 40-50% more rapidly than their solitary counterparts. (Wlliams, Kessler, Cunningham, & Jeffeies, 2000) Having said that, make note that we’re talking about complex assignments. For simpler tasks, it can be more productive for programmers to work independently.
As programmers pair, you eliminate a common problem where programmers are highly specialized and knowledgeable in only one area of the code base. This specialization creates more than one problem.
While it is great for job security on an individual basis, the company is at risk should this individual leave the company. There is also the problem that in order to keep this individual “productive” in some cases – occupied might be a better word – you will need to create more work than is truly necessary. At other times this person can become a bottleneck because you can have more work than one person can possibly deliver on in the desired time frame.
There are some other benefits that emerge as side effects of pair programming. First, there is a little “pair pressure” that helps maintain coding standards. Another is that while some programmers are resistant to the concept of pair programming at first, many also find greater job satisfaction once they get some positive experiences under their belt.
On a more cautionary note, keep in mind that as an activity, pairing requires greater mental effort on the part of both individuals because they will naturally work at higher concentration levels. This means that people will be tired at the end of a work day, so keep another principle of the Agile Manifesto in mind: “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
In closing, my final advice is to keep pair programming differentiated from mentoring. Pair programming should involve individuals who are reasonably close in knowledge and skill. Mentoring is a different type of pairing activity geared towards transferring knowledge and experience, with a greater investment of time required of the individual transferring his or her knowledge and experience to someone else.
This post is a draft of content intended for an upcoming ebook: Agile Expectations: What to Expect from Agile Development, and Why. Blog posts will be organized under the “Agile Expectations” content on the left-hand side for easy reference. I welcome your comments and feedback! – Dave Moran
Cockburn, A., & Williams, L. (2000). The Cost and Benefits of Pair Programming. Proceedings of the First International Conference on Extreme Programming and Flexible Processes in Software Engineering (XP2000).
Wlliams, L., Kessler, R. R., Cunningham, W., & Jeffeies, R. (2000, July/August). Strengthening the Case for Pair Programming. IEEE Software.
Wray, S. (2010, January/February). How Pair Programming Really Works. IEEE Software.