I’ve seen three types of companies when it comes to pair programming:
1. We pair program on EVERYTHING.
2. No, we don’t pair program.
3. We pair when we need to.
Of course, it also helps to define what I mean by pair programming, because there are multiple definitions.
For teams that practice the classic definition of Pair Programming from the agile practice Extreme Programming (XP):
Pair Programming is a method of developing software where one programmer sits and the keyboard and “drives”; starting by creating a unit test, and then the other programmer takes over and writes the failing/passing code for the test. In this definition, the act of switching for every unit test is key.
In teams that do not practice TDD, Pair programming is two sitting in front of a computer with one keyboard and mouse for 30 minutes – 6 hours trying to solve a problem.
Pair programming paired with TDD is a great practice when you have people who are trained in TDD that can guide new programmers. Being able to teach TDD is key — there are lots of wrong ways to do it, and they end in frustration with the practice of TDD in general.
Pair Programming to solve a problem without TDD is how most programmers interact, and opinions range from ‘great!’, to ‘meh’, to ‘omg do we ever have to do this again?’
Recently I spent about a week on a problem that with a pair took me about 6 hours to fix and if the entire component had been created through TDD would have never occurred. It’s also taken me many years of practicing TDD and pairing to know that it wouldn’t have occurred had our team used a TDD+Pairing process.
So why didn’t I TDD that component? In a phrase, because the culture doesn’t support it. There’s no mechanism to get buy-in for something that is arguably akin to wearing a safety harness on a job site. (If wearing said harness caused everyone on the site to have to learn how to work in safety harnesses)
If you’re trying to deliver software for a project where the code isn’t going to last several years, maybe TDD and pairing isn’t worth it. If the domain isn’t complex and deep, maybe pairing isn’t worth it. But if the code is going to last at least 3 years, it may just be, provided you’re willing to train your programmers on TDD and pairing together.