Summary: This week's episode on pair programming discusses where you might see pair programming, HashRocket's pairing setup, perceived and real disadvantages to pair programming, its advantages, and what it takes to do good pairing. Pair programming is usually associated with Extreme Programming. It is sometimes seen as a mentoring practice, but is actually a collaboration practice, not a mentoring practice. This is because both programmers participate equally, not one leading and the other following for long durations. Pair programming is done with 1 computer and 2 programmers. I've never seen it work well with 2 computers and 2 programmers unless one computer was being ignored or under-utilized. Obie Fernandez shared HashRocket's pairing setup and much more on his blog. The setup is not cheap. It's envied by many a programmer. Some of the disadvantages of pair programming (some of which are only perceived disadvantages) are: It ties up two programmers. It would appear that you're wasting at least one person's time. They programmer not actually programming. The problem with that statement is... which one isn't programming? They both are. They're both doing the same job. And in the end, I've experienced about 1 and a half times the work done in a pair as I or the other programmer could get done on their own. So, doesn't it cost more if two of you only accomplish 1.5x the work? Maybe. The quality of the code produced by pair programming is decidedly higher. This doesn't mean that pairs can't produce bad code, but it usually reduces the chances, which leads to higher productivity later on due to mistakes that were not made. Does this account for the other half of one person's work? Like I said, maybe. It's inconvenient and reduces flexibility. Sometimes it is inconvenient. I really enjoy working on something until it's completed. If I have to switch pairs and tasks, it really bugs me that the other task wasn't finished first. You also have fewer pairs than people, which means fewer tasks being worked on at the same time. The advantages are: Flexibility: If you pair on everything, then you can contribute to anything. This is a huge advantage. My friend and co-worker measures this depth of expertise in buses. "If I get hit by a bus, we lose all of our expertise in X." Pairing and sharing increases your bus-depth. (I still haven't been able to pair with him.) Code Ownership: If you worked on each piece of the application, then you bear some responsibility when it breaks. If you spread this across the team, problems get solved very quickly. Collaboration Nothing builds team unity like solving problems together. You also get the benefit of gaining your co-workers' expertise when you code with them. Here are a few things that are critical to good pairing: Communication: How many times did Chad Fowler mention communication? If you can't communicate well your intentions either verbally or through code, then you have one guy coding and another watching. This is where you validate at least one of the disadvantages to pair programming. Ability to work together If you can't stand the guy, or stand to sit next to the guy, you can't pair with him. His odor or personality will overwhelm your ability to communicate and concentrate effectively. Skill Level The company I work for has a strong mentality for "We don't hire idiots." Weeding out the idiots or not hiring under-qualified people really makes the team stronger and pairing easier because you don't have to spend time explaining, you can spend it working. Setup Read Obie's article. He really summed it up best. It's hard to work where it's hard to collaborate. Download this Episode
