When I served as a Branch Chief at USDA, I encouraged my developers to take on the practice of pair programming. This was a bit of a surprise to the contractor management; I was actually asking them to have two people do the same job? As a coach, I also encourage teams to try it out. I often find the same argument; why would I want to pay two people to do the job of one? Let’s explore the reasons behind that.
You have probably heard that pair programming improves code quality and wondered why that is.
My upcoming session at AgileDC will allow you to experience it by comparing development with limited collaboration to one where pairing is put in place. As a spoiler, you will see how pairing creates a shared mental model between each person of the product being constructed. It’s this shared, co-created mental model that improves the product, whether it be user stories, code, designs, or any form of output of importance.
Pairing allows questions to be raised about why choices are made. When it comes to pair programming, the person that isn’t typing (the navigator) has less mental distractions as well. Their interrupts to raise ideas or ask questions also causes the person that is typing (the driver) to pause, freeing their brain for some additional cognitive cycles on the problem at hand. It’s this extra thinking by both people that creates additional options, avoids errors, and increases creativity. The easy metaphor is to think of the code being built as a heavy object to be lifted, it’s easier with two people as opposed to one struggling with it.
Many managers think of pairing as simply an exercise for training and mentoring more junior people or for sharing specialized expertise. While this aspect could be beneficial, this is not the intention of pair programming. Pairing two experienced developers can help improve the product’s quality due to the questions and discussions raised during development. Even if pairing only occurs occasionally between the developers, the two developers learn more about each other’s coding and problem-solving style, which results in more congruence in how they work.
And while we’re mostly talking of pair programming, any form of creative problem-solving can benefit from pairing. One of our other coaches here at Excella worked at a company that also paired their product managers as well, producing richer and more complete requirements that got passed to the development team (which used pair programming).
So encourage your team members to try it out. You may be surprised at the increase in productivity and quality you get as a result. And if you would like to see this first hand, come to my session with the same title and I’ll run you through an exercise that demonstrates it. Want to hear more, come out to AgileDC!