Pair programming is a collaborative practice, in which two programmers sit together at one computer and write code. It flies in the face of the conventional image of the lone hacker sweating over a hot keyboard late into the night, and it is useful food for thought in terms of considering how programming can often be better done as a collaborative activity.
Pair programming as a practice emerged from some pioneering work done by Kent Beck in the 90’s under the banner of “Extreme Programming”, which proposes a set of practices for more rigorously developing software with less bugs in a more timely manner. Pretty much all of these practices are commonly applied in the industry today, yet pair programming languishes for some reason.
If it sounds uncomfortable, it is. Two grown men sitting together in intimate circumstances for extended periods (typically men I say, though inter-gender PP could likely make an even more squirmish combination) of time quietly arguing the benefits or otherwise of indentation-styles and data structure selection. This probably has a lot to do with it. Never mind the fact that the kind of person that usually becomes a programmer is typically quite driven, a little bit individualistic, and quite confident of their ability to make judicious implementation decisions without having somebody looking over their shoulder.
Also, I believe the need for enabling collaboration in this way has also been somewhat obviated by technology itself (instant messaging, screen sharing, code review tools being commonplace) and the development of more social development methodologies such as SCRUM.
I wrote what remains here as a comment to this article, but feedback seems to be disabled, and I didn’t want it to go to waste. The author discusses how pair programming is good because we only spend 10% of our time actually writing code. My position is the opposite …
I would question this reasoning, but the pie-chart does seem appropriate to me.
70% of your time reading code, does seem quite high, but I would definitely support the aspiration that we should be reading, and thus reusing old code more than we should be writing new code (if not in actuality, at least the knowledge therein). It is also true that the code is often the only definitive documentation for the software it constitutes and any programmer must be able to understand what went before, before they build upon it.
20% of your time solving problems seems okay, this is the time spent in the “problem domain”, acquainting with the “real world” aspects of the problem, and in the “solution space” determining how best to implement, and what tools and technologies to use. I think this is highly dependent on the nature and novelty of the problem itself, but as a “what’s left” after reading (70) and writing (10) code, it’s an okay number.
I would contend that the foregoing categories of activity should always be highly collaborative (also that some degree of coding is involved in them also – a note for managers of the behavioural persuasion), but that “pair programming” is all too limiting a collaboration model for these. The nature of reading may always be quite solitary, though it should be supported by questioning and open discussion. Problem solving should be aided by group discussions, the scrum standup, whiteboard sessions, simulations, prototyping and adversarial testing, as well as an open and friendly work environment.
Pair programming then, can only really be applied to the remaining 10% of activities, at which point we have to ask is the discomfort worth the payoff? As you say “one keyboard for two pairs of hands can only be a limiting factor”, but at this stage I would consider slowness a virtue. It is at this stage that you commit the work of the remaining 90% to code, and mistakes can be costly. For this reason being forced to go more slowly is beneficial, as is the second pair of eyes. The second brain engaged can also prevent idiosyncratic “hero” code slipping in …
But all told, much of these benefits can be enjoyed through code reviews, some self-discipline, and strong technical leadership. That’s not to say PP doesn’t have its place, but the benefits are often overstated, and as a practice that is as uncomfortable to the typically individualistic programmer as I know it is, it will rarely be among the first things they call upon.