Of all the software developer practices I teach, the one I get the most resistance from managers is pair programming. They tell me they have too much work for their team to do and if they paired then their developers’ throughput would be cut in half.
There is a naïve assumption in that statement. The assumption is that the limiting factor in software development is typing. I think most developers would disagree.
When developers pair they produce significantly less code to do the same job as they would on their own, which drops the cost of maintenance. They also produce significantly fewer defects so there is less time spent debugging, which is usually where the real bottleneck in software development is.
Some tasks are more efficient to do in pairs. If we had to move a 100-pound desk from ten offices to the offices across the hall and we had two people to do it, it would probably be more efficient if they worked in pairs. In software development, I find lots of activities that are good to do with a partner—initial design, naming variables, debugging, refactoring, etc. If you believe that code reviews are a good thing then pairing is a code review as it is being written.
There are many ways to practice pairing. Generally, it involves two people sharing one computer who take turns “driving” and “navigating”. The driver is the one using the keyboard and mouse. The navigator is looking over their shoulder and thinking about what is next. They work for a while and then switch, taking turns anywhere from every 2 minutes to every few hours, but shorter is better so we recommend swapping driver and navigator every 4-6 minutes.
There’s also Ping-Pong pairing where one person writes a test and the other person implements it and then writes a test for the first person. Pairs rotate throughout the team one or more times throughout the day or by story or iteration. How it is configured depends and has an impact on its success. I recommend trying all configurations and seeing what works best for your team.
As a developer, I have a love/hate relationship with pairing. I love pairing on development projects because I learn so much but it is also harder work than if I was on my own. I have someone watching over me the whole time so I can’t be slacking and I can’t be falling back on bad habits.
So pair programming is a great way to help teams adopt new practices, such as TDD because if we fall back on old ways and start to write our code before we write our tests, there is someone there to catch us and remind us. The secret that managers are not aware of with pairing is that we will tend to work a lot harder when we are pairing. The good news is that our extra efforts are usually rewarded by learning from other developers by seeing the way they do things.
For a lot of developers, programming is a solitary activity. When we pair we learn little tricks that others have figured out that can help boost our productivity. Pairing also promotes collective code ownership. No one piece of code is “owned by” a specific individual. It also helps spread knowledge across a team. In fact, I know of no other faster way to propagate knowledge throughout a team than pair programming, except perhaps good training.
Like with most technical practices, it has to be done correctly in order to gain the most value from it. I recommend frequent swapping within pairs and frequent reforming of pairs to keep things interesting. We naturally gravitate to people who are like us but I find the best pairs are composed of people who are different from us–an introvert and an extrovert, a pragmatic thinker and an abstract thinker, etc.
Pairing is the fastest way I know to propagate knowledge and good habits across a team. It promotes collective code ownership and helps get everyone on the same page when building systems that require a team effort. These are just some of the reasons that I consider pair programming to be an essential practice.
Previous Post: « Drive to Testability
Next Post: Polymorphism »