I really enjoyed reading Stuart Wray's article, "How Pair Programming Really Works," in the Jan/Feb issue of IEEE SW. It's nice to see an author bring appropriate bits from the enormous amount of research in cognitive science that applies to our industry.

The big message in this article is so important -- not just for pair programming -- but for all
practices, especially those that are "agile-flavored" -- it's not about the "other pair of eyes" --
it's about the other brain and the other set of life experiences. In retrospectives it's always
surprising to hear how different team members "saw what happened." Unless we share all these different views, we can't hope to learn as much.

Thanks, Stuart!



Linda Rising
Independent consultant

Posted on 1/8/10 12:02 AM.

What a delightful article - about the reality of programming. So many experiences as a programmer came to mind, when reading this article. Here are my comments about the 4 mechanisms.

1. I and a fellow programmer explained 'problem-bugs' to one another in the 1970s. We joked that we only needed a full-scale cardboard cut-out of each other to explain things to. On reflection, perhaps we were wrong: Stuart Wray's point about the quality of questions is very telling. One always went to someone who could be regarded as insightful/perceptive. So yes - Mechanism 1 is close to my experience.

2. I 'pair-programmed' back in the 1980s (feeling slightly guilty at the time - many thanks to Kent Beck for bringing it respectability). It worked, and I heartily concur that it was not driver-navigator. It was two people debating higher-level architecture issues, or seeing clashes of intent and proposed coding, or noticing semantic inconsistencies - and of course spotting typos. The big wins were a) the architecture debates - places where the detail of coding would confront us with much larger thoughts about the whole structure, and b) the clashes of intent and coding, and semantic inconsistencies - places where we saved a lot of time by avoiding constructing code that had fundamental weaknesses. So again - Mechanism 2 is close to my experience.

I am less comfortable with Mechanism 3. (Though I fully agree with the programmer interview scene he paints). My guardedness may relate to having been 'brought up in the Dijkstra era': I greatly admired a mainframe operating system maintainer colleague, who wrote and desk-debugged c. 300 code patches a year, and was mortified when 1 patch did not work right first time - he targeted zero defects, and 0.3% defects was just not good enough. I am wary of the convenience of the modern coding environment - it can seduce one into low-grade work. I often leave the office and find a quiet room where I take time to craft my code thoughtfully, or desk-debug similarly.

I quite agree too, that understanding each other's ability level is much improved by programming together. The notion of more accurate estimating appeals intuitively but I never actually tried it. Overall, Mechanism 4 seems to work.

I look forward to further work on this subject.

My thanks to Stuart too.
Andrew Main

Posted on 1/13/10 1:13 AM.

Thank you Stuart, this article was full of thought-provoking ideas about how developers work. here's a couple of tangents:

The idea that code-and-fix programming is reinforced by operant conditioning is interesting, but I think that generally, the explanation is more mundane: most people do a lot of trial-and-error when learning to program, and many never get far beyond that. Doing so requires stepping up to a new level of abstract thinking, and we don't seem to do a good job of teaching that.

Perhaps part of the problem is that programming is somewhat deprecated in comp. sci. and software engineering -- it's sometimes looked at as just technicians' work. I think this is short-sighted, partly because I suspect software engineering is best taught bottom-up: I think a person who has learned to rigorously model and reason about mere programs has made an important step towards doing the same with systems.

I think you are right in suggesting that interactive tools facilitate this bad practice, while pointing out that this isn't a good enough reason for giving up their benefits. Like so many useful things and ideas in development, they are double-edged swords, and the general approach to potentially dangerous tools is proper training. Unfortunately, the trend in education seems to be in the opposite direction: perhaps guided by the disdain I mentioned above, it is towards a more interactive, experimental, vocational or 'real-world' experience. Perhaps we should ask why, if the state of practice is sub-optimal, are we moving education in that direction?

The fact is that even people who know better succumb to the 'just do it' imperative, and fall into trying fixes, rather than thinking about solutions (I'm writing about myself here). As it happens, my current job has me commuting by train, and when I have a particular problem to deal with, I can work on it while on the train, but I can't try anything. As a result, I often think of better ways of doing things than I would if I were not constrained this way, and I think there would be value in having students do something similar, so they can see that it works.

The point is that the the best way of working is not the intuitive one, even if, intellectually, we know better. This doesn't have much to do with pair-programming, except that, given the right pairing, perhaps someone who is ready to make the next step could be nudged in that direction by someone who is already there? I know I have learned things from experts, not just because they prompt me to reach deeper into what I have in my head, but simply because they have shown me something new to me, that works. The goal of pair programming is to produce working code, not to teach, but the latter will help the former in the long run.


Another thing I would like to respond to is Peter Carruthers comment about speech being both an input and output medium. Even more relevant, I think, is that it is not just a medium of communication, it is the medium of rational thought. My guess (unsullied by any actual research) is that we use visual models to reify our ideas, so we can apply our intuitions to them, but we need language to construct these models, and to explain to ourselves why they are relevant and what they mean. In this view, language doesn't just ask questions of, and get information from, our other mental modules, it actually makes sense of what they are presenting us with.

As for the expert effect, two thoughts occurred to me as I was reading. Could there be a competitive aspect to discussing our problem with an expert, which prompts us to strive harder and perhaps more desperately? Could it have something to do with mirror neurons -- no matter how hard we imagine a dialog, the imagined listener doesn't excite our subconscious the way a real person does? I am thinking particularly of those occasions when the expert doesn't have to say anything to be effective: this happens to me sometimes, but I have no idea how common it is.

Enough already! Many thanks - Andy Raybould.

Posted on 1/14/10 1:31 PM.

I'm one who finds pair programming absurd. I suppose I've done it, on occassion, mostly in search of recalcitrant bugs, but for mainstream development - one keyboard, seriously?

Remember, the benchmark for effectiveness has to be the productivity of two (2) developers working separately.

My analysis is that the process of communicating with a partner slows me down by 90% or more, and I do not see any offsetting increases in quality or any other benefits. A merger of skills? I hope the individuals have sufficient skills for their work, and if not, it sounds to me like the old theory that tying together two rocks wil enable them to float.

So, while this article is nice enough in saying what works about pair programming, from my quick read it makes no claims that the entire exercise is worthwhile.

Posted on 1/21/10 2:38 AM.

I was involved in two different projects between 2003 - 2005 that involved agile methods which included some form of pair programming.

Project 1 used pair programming for all aspects of development, from design to implementation to fixing bugs. This project failed because it was late and over budget.

Project 2 used a modified form of pair programming. Design and implementation of complex components were done in pairs. All remaining (non-complex) components were designed and implemented by a single engineer. Component integration was usually done in pairs, but not always. The issue of complexity was left to the assigned engineer(s) and lead. Fixing of bugs found in QA was left to a single engineer to fix or enlist help if they were having issues identifying and/or fixing the problem. This project came in ahead of budget and schedule.

What did I learn? Quality of the code had nothing to do with whether it was written by a single engineer or a pair. Unit tests were the key to reducing total bugs found in QA. The more unit tests a component had, the less bugs found in QA. This was true across both projects.

However quality of the design was greatly increased in pair programming (as compared to other projects I have been involved in).

Would I do pair programming again? No.

Posted on 1/21/10 6:04 AM.

Good article.

I encountered XP (eXtreme Programming) circa 1996. I practiced "solo XP" for circa 6 years - test driven design, refactoring, etc. I agree with other posters that unit tests and refactoring are key to code quality.

I have worked in small pair programming teams on several occasions over the past few years. Often only 2 people, myself and my pair programming partner, in the team. Occasionally with interns and other short duration team members. From my point of view all experiences were positive and productive. Can't talk about project success, since all were "Blue Sky Research" projects, but the software aspects of the projects were well done.

My first pair programming experience was side-by-side: my partner and I in a conference room, working on different laptops. Often one might be working on a test, the other the code. Frequently swapping. Often driver/navigator. At least, we often said "Let me drive" to our partner.

I have also worked in "facing each other" pair programming: 2 people in a conference room on opposite sides of a table. Not lloking at each others' screen all the time. But frequently talking back and forth, and occasionally saying "look at this".

Finally, the last 2-3 years of pair programming was the supposedly classic single keyboard / single display model. Mainly because my partner did not have a laptop, so we worked in my office. Also because my office had many large displays, rather than the small laptop displays. Frequent "let me drive" swapping of keyboard. Much to my surprise, single PC pair programming worked pretty well. I would probably prefer to have the option of being able to "go parallel" and work on separate PCs briefly, but I think that you must resist the temptation to go totally independent. Frequent and constant interaction is the key to pair programming success. Frequent and constant code review.

I mostly agree with Stuart Wray's 4 principles, although I might tweak them, emphasizing other aspects:

Mechanism 1: Pair Programming Chat

Yes, I think that one of the big advantages of pair programming is that a good team gets stuck less often. Solo, I can program brilliantly - but then get stuck for days. In pair programming I seem to get stuck less often. It's not just the potted plant effect. Oftentimes the other partner really solves the problem. But also, oftentimes, having a partner forces you to be more pragmatic - instead of thinking about the best possible way to solve a problem, you might be willing to compromise on a way that is good enough for now. Lest people start yelling "kluge" and "poor quality", (1) oftentimes the compromise is what you might do anyway, once you have exhausted the other possibilities, and (2) your partner usually will not let you do the really ugly kluges.

Plus there is the usual effect of differing skill sets.

But there are other important aspects to "chat". In my research domain, oftentimes one needs constant communication with other members of the team. Computer architecture simulation: the memory execution unit has got to talk to the cache has got to talk to the bus/interconnect. I think that one of the most important aspects of pair programming, or of any "war-room" development methodology where people are in the same room, is that you can talk to each other quickly, rather than send email, wait until the next project meeting, or even just walk to somebody else's office/cube (often to find them not there). With pair programming and other war-rooms the overhead of communication is reduced dramatically.

Note that I say "pair-programming and other war-rooms". At Intel we used to create "dungeons" where people worked intensely together for weeks or months to solve problems - usually at the end of a project death-march, when the pressure was high. Q: If war-rooms are a good way to get things done, why not work in them all the time? A: burnout. Pair programming is in a way the lightest weight war-room, the one least likely to produce burnout.

Mechanism 2: Pair programmers notice more details.

Yes. Constant code review. Nuff said.

Mechanism 3: Fighting poor practices

Again, yes. Constant code review. In a good pair programming situation, one partner will not let the other take a quick and dirty trick. (Although I have also seen the other side, race to the bottom.)

Mainly, I think that all good programmers are embarassed when they write bad code just to be expedient. But sometimes, I admit, I have dome so. I'm just less likely to when pairing.

Mechanism 4: Sharing and judging expertise

Immensely valuable. Most of my pair programming experiences have been with guys approximately my peers - and still I learned techniques from them, and them from me. And when I have been pair programming with junior, much less experienced programmers - yes, they have learned much more quickly than they would otherwise have, but still I learned from them.

--

I have already mentioned lower cost communications, as an aspect of mechanism 1.

I would add to this list "Staying on target". Simply put, I find that I, and other team members, spend much more time working, coding, and much less time responding to email (not personal email, just email from coworkers about other aspects of the job), etc. So much so than successful pair programming teams must reserve time - 1 or 2 hours a day, or a day a week when rotating pairs - for non-programming work.

It must be said: I find that 8 hours of pair programming is more exhausting than 16 hours of solo work. You simply work harder while pair programming. (And few people would say that I don't work hard.)

--

Would I pair program again? Yes, in a heartbeat. I'm not pair programming now.

The last thing I want to say is that I found pair programming quite simply more fun than working without pair programming. In part because I like coding, but as a senior computer architect I was spending less time coding and more time attending meetings - often to coordinate the activities of junior coders. Pair programming allowed me to coordinate, but also allowed me to code more, rotating between partners. So, definitely, pair programming versus attending meetings, IMHO the coding wins.

But pair programming even wins over solo programming. I hate to admit it, but I am a social animal. I like teaching people. I enjoy interaction.

Let's quantify this:

I earn roughly 200K$/year as a technical expert in my field. (Computer architecture; hardware design, but also a lot of software.) [Sometimes more, sometimes less, depending on the phase of the moon and bonuses.]

I'm fairly sure that I would accept a pair programming job for 150K$ a year. Even if it wasn't in my main area of current expertise. In fact, pair programming would be one of the things that would allow me to cross over to another field.

Possibly even 100K$ a year.

I.e. I would be willing to take a significant salary cut, just to get the better job satisfaction of pair programming.

Or another data point: I left my last job in part because what had been promised to me as a pair programming role turned out not to be.

I would always rather have interesting work and pair programming. Years ago I would confidently have said that interesting work would outweigh any working environment aspect. Now, I think that I would be willing to pair program outside my foeld, on less interesting work, rather than solo work on interesting stuff in my field.

Posted on 1/21/10 9:52 AM.

Hi all.

My first couple of years coding was basically exactly what is described here, although I was not aware back then that it actually was a recognized coding practice. I'm of course talking mid to late 80's but perhaps the term only came about much later.

My friend and I was still in school (grade 10). He was hitting the keyboard and I was reviewing and also sat with all the documentation (for Turbo Pascal back then). Also keep in mind there was no Internet back then, his computer (a 286 if memory serves me correctly) only had two floppy drives and compiling anything took for ages while some one had to continually swap out floppies if prompted.

From the above I guess the only reason he was the "driver" was because it was his computer. Be it as it may, I actually enjoyed the experience back then. But to be perfectly honest, I don't think I would like to be (or have) a back seat driver today. Back then it was because of a lack of computers that we did pair programming - even at the school's computer lab each workstation was always shared between two people. Today we have the luxury of every one having a computer of their own. I also think a lot of tools exists today for developers to exchange ideas without being physically next to each other. This is especially true for developers participating in FLOSS projects through portals like SourceForge.net.

Finally a note on our current work environment. I work for a large banking group in South Africa. What we have done was to take the open plan office idea and make it even more open. The typical layout is a floor area with tables all joined in the center of the floor area with no partitioning. Think of it as a round table where everybody can see each other. The outer walls of the floor area is covered with magnetic white boards. What this does is encourage developers to talk to each other.

So each developer will program away and only engage in a discussion if he or some one else run into an issue. It is easy in this set-up to quickly brain storm a problem. During other "normal" coding periods, most of the developers still have their iPods in the ear to eliminate any other distractions.

So I guess at the work place at least we got close to but not actually implemented pair programming. I think we are at a comfortable middle ground, giving developers an opportunity to "pair up" only when required. This seems to work well for us and perhaps other could try this too.

Posted on 1/21/10 12:37 PM in reply to Andy Glew.

I have never experienced pair programming in my over 30 years of programming, but I can see how it can work to produce a more comprehensive approach to getting the job done. I always think of the features that are needed...the problem is that I often don't see everything until it's too late to do much about it without starting over.

I can see where pair programming can keep you honest and allow one person to be "reflecting" while the other is coding.

Great article.

Posted on 1/22/10 1:12 AM.

I think you are probably right that when we talk to people we regard as experts we are more "keyed up" --- we don't want to embarrass ourselves. Even though we are going to them with a problem of our own creation, we want them to have a good opinion of us. It makes sense that for a competent programmer, this extra pressure would improve their performance.

Regarding "just do it" slot-machine programming, and the benefits of stepping away from the machine, I agree that this often helps. Sometimes the solution to my bug has come to me in a flash in the library when hours at the computer did not help. But exhorting people to "be good", to step back and think, seems to have a very limited impact. I continue to be amazed at how, each year, students in my programming class end up trapped in a cycle of hopeful tinkering. Without stopping to understand their problem, they make a change to their code, "put a coin in the slot" and hope for the best. Sometimes it works. It's clearly compulsive!

When we are forced to step back, then I think this can help avoid these periods of futility. But I think that if we have the discipline to use the available tools in a more productive way (e.g. by thorough unit testing) then that's even better. Pairs can help with both, but we have to remember to agree ahead of time on how we are going to work.

Posted on 1/22/10 9:39 PM in reply to Andrew Raybould.

I wouldn't claim that pair programming is good for everyone, or for all kinds of development activities. Although the experiments on pair programming don't usually show a doubling in speed, they generally do show some reduction in "wall-clock" time to finish, compared to a solo programmer doing the same work. So, for some people, pair programming is a way to add programmers to a project and get an earlier delivery date. This is rather surprising, since it directly contradicts the conventional wisdom that "adding programmers to a late project makes it later".

> Remember, the benchmark for effectiveness has to be the productivity of two (2)
> developers working separately.

I would say that outside of experiments, the true benchmark of effectiveness would be to compare the productivity of a team of pair programmers with a team of solo programmers. When you factor in the interpersonal communication and training necessary to keep a team functioning over a long period, you might find that the apparent inefficiencies of pair programming are not as severe as they first appear.

Posted on 1/22/10 9:54 PM in reply to Joshua Stern.

Thanks a ton to you, Stuart Wray. I have not only enjoyed reading this article but also got an insight into how 'Pair Programming'(PP) really works.
When our team was asked to follow the 'Pair Programming' practice (when we really do not understand what it is excatly), wherein we were divided into groups of two and were assigned tasks, we just started hoping to learn more and discover what are the benefits of practicing it. At the end of the Sprint, our Lead was a bit disappointed (no surprise!) as the team members raised questions like 'how is it different from what we were doing all these years' , 'we didnt feel like we were into a new development practice'!!
A little introspection would answer all their questions - they were all right as we never followed 'the real pair programming'. Probably, most of them by now would have realised that just working in groups of two on a given task would not be pair programming!
The other day when I was trying my luck at 'Road Rash', with my best friend right next to me, and I ended up coming first in the race, I think I have realised what PP actually means. While I was all the time concentrating on the speed and the sharp turns in the game, my friend kept on telling me how far a vehicle is ahead of me, where do I stand in the race, how far is the dead-line and when to hit the guy following me!!
And today when I was reading this article I have realised how far a littile experience can take us to.
Stuart, your expertise can add to peoples experience and help them make the best of 'pair programming'.
Again, thanks a lot for this fantastic article.

Posted on 1/27/10 6:29 PM.

Very nice article, touching on both the psychology of programming and software engineering practices dimensions.

In an article destined for a large population of practitioners, it would be nice to promote and support collection of data and empirical evidence. Is there a follow up that can be offered to the readers of this article - a place in which they can contribute some useful empirical data?

For example the concepts and definitions related to the psychology of programming could be themselves the subject of some validation by practitioners.

Then moving into the software engineering practices, collect data first on the more concrete aspects / variants of pair programming practice mentioned here (no pairing, asymmetrical role pairing, short rotation pairing, etc).

It is always difficult to isolate practices and their relative impact in empirical studies, but if we establish concrete attributes and an unambiguous meanings, we can collect some meaningful data about this practice.

Then we can ultimately work to establish relationships with other practices and factors.

Posted on 3/14/10 2:05 AM.