My last post on Pair Programming detailed the top 3 situations in which to leverage pair programming. In this third article of the pair programming series, we’ll look at common problems with the physical workspace that can hinder the effectiveness of pairing.

Continue reading →

Pair programming is exhausting. The level of focus required takes more energy than working by yourself. Not to mention that your schedule, personal needs, and downtime are no longer under your control. For these reasons it’s best to use pair programming on a short-term basis to accomplish a specific goal. Its usage is similar to that of a Navy SEAL team deployed for black ops; performing a task with a specific objective that must be achieved in a limited window of time.

For a summary of the roles and responsibilities in Pair Programming, please visit this link. Continue reading →

Experienced pair programmers claim that the code they produce is better than what they would have written on their own. But how exactly is ‘better’ measured? Most research studies on the topic measure it by the number of defects produced. But this type of analysis is over-simplified since code can be evaluated on many aspects including security, extensibility, simplicity, and the list goes on.

There’s also an aspect of subjectivity when measuring what is ‘better’. What’s better for one developer isn’t for the next. In that sense, it’s almost impossible to genuinely evaluate which code is best.

Continue reading →

Pair Programming can be productive, useful, and churn out better code than a lone developer. Some organizations, such as Pivotal, do everything in pairs. There are also strong opinions in the other direction. Over the next month, I’ll be publishing a series of posts on the subject because it can help developers write better code when used correctly.

Before we get into the finer points of when and how it should be used, I’ll take a stab at redefining Pair Programming with a new analogy.

Continue reading →