29 Jan 2009 - San Antonio

I recently found this post, Pair Programming all the time, by Jay Fields and loved it. I’ve felt the same way about pair programming.

“I define all the time (in terms of pairing) as when I’m writing code that I’m going to commit.”

That is perfect. Common sense but stated explicitly. I worked in an Agile shop for 2 1/2 years and the environment was setup to highlight pair programming. Pictures and little explanation here (Thanks Joe). We even marked tasks in the stories as low (L) or high (H) to dictate whether a pair was necessary (this was decided during our modeling week by the two developers who tasked the story, but always up for discussion during the iteration). It worked out pretty well.

I understand and have heard all the reasons to not pair program. Sometimes it works and sometimes it doesn’t. I’ve personally experienced the benefits. You learn to work with different personalities and that can only benefit you in your professional career. And, the obvious reason, is immediate code review. But, as my friend Scott C. Reynolds says (more or less):

“Not everyone is cut from the same cloth”

That is true and that is life. I hope this helps someone understand that not all pair programming enthusiasts are zealots. I know it’s a fine line though.