In short, I find its benefits overstated and the downsides overlooked. Also, the attitude that if you don’t like PP, then you must have some superiority complex (evident in some comments here) is ridiculous.

Pairing requires lots of preconditions to be met to work properly, and even when it does, the loss of productivity and newly gained inertia are by far greater than the gains in code quality or learning.

I think that might sound right when you type it out, but it’s not reality. If you just got out of developers way (and I am a former one), people would just do whatever they wanted. Dev A would test, Dev B would also test, but use a different tool, and Dev C would just sit on Facebook all day. In a one or two person shop, it might work, but I have hundreds of developers that I am responsible for (either directly or indirectly). I can’t just get out of their way or nothing will ever get done, and no standards will ever be followed.

I know the purpose of this post by Derick was just about some personal observations, and we’re well off that beaten path. But if there are any real PP studies that can’t easily be ripped to shreds, I’d love to see them. As I mentioned earlier, I have to “prove” everything before I’m allowed to implement it, since you can’t just say “Let’s give Unit Testing a try and if it doesn’t work in a few weeks, we’ll kill it” when you have over 100 people involved.

Again, whether other processes provide a more cost-effective strategy depends upon the circumstances and goals you’re trying to accomplish.

In my opinion, a better analogy would be the needs of a family settling in the wilderness in early America (think little house on the prairie). After choosing the home site upon arrival, the first thing that needs to be done is to establish a shelter … and fast. While some discrimination will be exercised when building their temporary shelter, any measures taken will be made with the temporary needs of the structure in view. Once established, a homestead will be constructed which will better withstand time and the elements.

In some circumstances, it can be faster and cheaper to develop a solution without maximizing the engineering and quality assurance best practices of the industry, and depending upon the needs of the business this may be the right solution. For long-lived endeavors, such strategies can prove to be more expensive when considering the total cost of ownership.

Concerning my statements regarding the SDLC, the point I was trying to make is that getting buy-in from front line managers, managing directors, vice-presidents, etc. on a particular development methodology is a larger topic. In my opinion, whether the development team should be, for instance, employing code reviews or pair-programming isn’t ideally a decision that should be being made by upper level management … or even the development manager. If you are paying a team of engineers six figures to accomplish a task, get out of their way and let them do their job.

“Post development processes such as code reviews, cross-training, etc. tend to become less necessary, and mandated adherence to standards tend to be replaced by more organic homogenization of best practices and preferences, but none of what you’ve listed are necessarily mutually exclusive to pair-programming.”

Agreed, but PP is just the most expensive (or at least like so) solution to these problems. If my task is to get the the airport, PP is the stretch limo of options, while “cheaper” methods are the cab. Would I prefer to take the limo? Sure, but it’s hard to justify the dollar amount when there are other forms of transportation that do the job nearly as well.

“This begins to enter into the realm of agile vs. defined SDLC processes which is probably too lengthy to discuss here.”

I don’t see it that way, it seems that most of the reasons listed for doing PP are more related to distractions, which I don’t think is SDLC related, its more developer related.

Let me put it this way, if I have to go to my boss and explain that it takes PP to keep developers from being distracted and working, I might as well be saying “fire me” while having a big L on my forehead.

“… there are plenty of other mechanisms that can achieve the same results without Pair Programming though. And by “other mechanisms” I mean “cheaper”. For example code reviews can improve code quality, standards/snippets/.templates can guarantee style consistency, etc.”

I don’t disagree that other processes exist that can help improve quality and consistency, but through my experiences I’ve come to believe that many of goals of such processes are more effectively achieved through the practice of pair-programming. Post development processes such as code reviews, cross-training, etc. tend to become less necessary, and mandated adherence to standards tend to be replaced by more organic homogenization of best practices and preferences, but none of what you’ve listed are necessarily mutually exclusive to pair-programming.

Concerning the claim that these other processes are “cheaper”, this may or may not be true depending upon a number of factors, not the least of which is the needs of the business. Some of the processes you mentioned, particularly code reviews, provide only a fraction of the benefit that pair-programming can and depending upon the type of application you are developing they may prove to be a less expensive route to achieving that subset of benefits. They may also prove to be a more expensive route if the issues for which pair-programming would have aided in begin to surface. I’ve always liked the analogy of the Amish and IKEA’s construction methodologies. One emphasizes quality, the other affordability. Which is better depends upon your needs.

‘The hardest pill to swallow for management is “So, let me get this straight, these guys make six figures, and yet I need two of them to work together to code up a few web pages?”

Again, as a manager, unless I’m getting more than 200% efficiency from a pair of developers (granted, that’s incredibly difficult to measure), I can’t sell the idea to MY boss, let alone sell it to the CTO of my company.’

This begins to enter into the realm of agile vs. defined SDLC processes which is probably too lengthy to discuss here. What I will say is that, ideally, development teams are empowered to chose the development process that are best suited to the needs of fulfilling their responsibilities. At worst, those at more executive level positions shouldn’t be concerning themselves with how the bricks are getting laid, so to speak. One might also ask, “So, I’m paying these guys six figures and they still need their hands held? Aren’t you hiring professionals?”

On the other hand, if you want to kill off pair programming in your team, I wrote a great little how-to article a while back to help you out: http://www.awkwardcoder.com/index.php/2010/08/27/10-ways-to-kill-pair-programming/

I also see many of you commenting on 2 people 1 keyboard. I do see how a co-pilot in the cockpit can help a little, but that is not how we PP. Each of us have our own workstations, we sit side by side and use real-time editing plug-ins to work on the same code at the same time. We communicate with each other about what is going on what we are doing and while both of us work on the same feature or function at the same time we often work in different parts of the code.

also keep in mind that your experience is your own – not anyone else’. don’t assume your experience or preferences are the only ones that are valid, either.