Pair Programming

In the absence of a generally accepted definition of pair programing, for the purposes of this post I define it as two programers sitting at the same computer engaged in working on the program at hand.

I see pair programming as one form of collaboration. Other common forms of collaboration on a a software project include:

• two people standing around a whiteboard discussing the same topic


• in the case where people are sitting at their own desks, asking someone nearby a question about their current work

On a side note, Dave Thomas has talked about having a customer (the person with 'requirements') paired with a developer. This sounds like an interesting idea to explore for some situations. Although I don't think using current, mainstream enterprise technologies (eg. Java, C# based) would be suitable here, due to the time it commonly takes a developer to do something that would be meaningful to the customer.

My expectation of software developers on the teams I am involved with, is that for whatever task they are working on, they will choose to collaborate with their other team members in whichever ways bring the best business value. Some factors that I have considered in such a decision include:

• complexity/familiarity with the task


• skills and abilities of the team members


• knowledge sharing - in a tangible sense this translates to things such as skills transfer between team members and setting up the project to function appropriately in the case of a team member being unavailable

By the previous statements I disagree with extreme programming and the derivatives that mandate pair programming for all committed code (or are increasingly working towards that objective). Of the numerous projects and people I have been involved with over the last five years, I have not seen the case where such a rule would deliver the best value to the customer, or close to it.

To clarify, I am not blatantly for or against pair programming. It has situational benefits and costs, just like the other forms of collaboration.

Finally, there is one factor that is rarely mentioned by others in my discussions on this topic. That is pair programming sets up a more social work environment, which some people really enjoy more than others. This blog post is already long enough, so I won't comment further on this, except that I would like to see people be honest with themselves if this is a motivator for them. Especially if they are trying to convince others about pair programming.