We have been on a bit of a hiring spree recently. As part of the hiring process I try to make sure the candidates know what they are getting into if they join our group.
“We do virtually all of our work using TDD and spend 80-90% of our time doing pair programming. How do you feel about that?”
On hearing this, many candidates shuffle uncomfortably and glance furtively around the room. “You don’t actually do that, do you? The pair programming thing, I mean.”
This is probably the question we field the most from candidates in our interviews. Indeed, we do use pair programming almost all of the time. What’s more, even though there is a lot of peer pressure to pair, nobody is forced to do so on our team.
While pair programming has gained some acceptance in the industry lately, it still isn’t pervasive. Many people have experimented with pair programming to help solve tricky problems, or to get introduced to a new area of code, but relatively few people have tried pair programming over a number of contiguous days. “Isn’t it slow and wasteful?”, they often argue.
Pair programming on a regular basis is a very difficult discipline. It requires a set of skills that many programmers have not had much experience with. It also requires a significant amount of practice before one can do it well. Once proficient at it, though, a good pair can perform both better and faster than two people working alone.
I think one of the biggest problems that beginning pair programmers have is that they view the discipline as merely a continuous code review. They refer to the non-typing party as the “observer” whose role is chiefly to catch mistakes. If one does pair programming in this fashion, I think it is understandable to see the observer as being something akin to a very expensive spell checker. Are they actually doing anything that can’t be done more cheaply with code reviews?
At the risk of being controversial, I will say that catching errors is not one of the benefits that I am looking for when pair programming. Don’t get me wrong, I value the extra set of eyes when pairing, but for me this is the smallest benefit you get. In fact I see pair programming as a way of significantly improving the speed that a team can generate code. There are several areas where this improvement can happen: communication, separation between coding and planning, and a programmer’s ability to concentrate.
First and foremost, pair programming fosters improved communication. A team will always have disagreements about design and coding style. When pair programming, you always have immediate feedback for your ideas. Conflicts are brought out early rather than left to fester. Importantly, controversial code doesn’t get a chance to become entrenched in the code base. Because feedback is immediate, you avoid the situation where you are forced to accept something simply because it is finished and rewriting it will take too much time.
Our team actually does code reviews and pair programming. A pair has a much better chance of getting controversial code through a review than a single person does. Having at least one other person listen to and understand the reasons for doing something makes it easier to explain to others. This saves a huge amount of time and enables the team to bring on new techniques that might otherwise be too controversial to accept otherwise.
One of the things that people ask me once I have asserted that we really, actually pair program is how to do it effectively. Probably the best way to learn pair programming is to do Ping Pong Programming. It is a simple technique where one person writes a failing test and the next person makes the test pass. After making the test pass, the second person writes another failing test and hands the keyboard over. Just keep doing this over and over again.
As this technique is best suited for development of new features, it works extremely well when doing katas for practice or fun. In fact, if each person tries to do the least possible work while simultaneously trying to force the other to do the most possible work, it makes excellent TDD practice. There are many places on the internet where you can find good katas. We had a lot of fun doing the katas on cyber-dojo, though it appears to be down as of this writing.
Ping pong is an excellent exercise for ensuring that both parties get equal access to the keyboard and are engaged in the process. It is not the best technique for all situations, though. Many times it is better to use a driver/navigator approach.
I often think about this style of pair programming as being similar to the driver and navigator in rally car racing. A rally car race is a stage race where participants drive a long course, usually on normal roads. It is impossible for the driver to memorize the entire course, so a navigator accompanies him. The driver’s job is to drive as fast as humanly possible without crashing. The navigator’s job is to plan ahead and warn the driver of upcoming corners or difficult areas. Usually the navigator uses some kind of code to tell the driver which gear he must use, or how fast he can take the corner. The advantage of having a navigator is that the driver can drive much faster than they could if they were driving alone. The driver is freed from thinking about what is coming up and can devote their entire attention to driving quickly.
In driver/navigator style pair programming, one person, the driver, is in control of the keyboard. The driver’s job is to write code, while concentrating on the task at hand. The other person is the navigator and their job is to plan further ahead, keeping notes for possible upcoming work. Often the navigator will keep the big picture in their head and plan what needs to be done. When the driver finishes a section of work the navigator can take over, having already come up with an idea of how to tackle the problem. This separation between coding and planning allows the driver to code much faster, as they can rely on their partner to plan for upcoming potential problems.
Whichever way one does it, one of the main benefits of pair programming is improved concentration. I imagine that every programmer has experienced “white page syndrome”. When you have a problem that you must solve, but don’t know where to start, sometimes it seems too daunting and you just stare at the blank page wondering what to do. Other times, programming can simply be lonely and boring. Having someone beside you who can cheer you on is an amazing aid. When one person is feeling down, or listless, the other person can help them over the hump.
Many people have heard of the mental state called flow. Getting into a flow state and maintaining it is essential for a high pace of development. Lately, however, there have been a few blog posts about the potential downsides of encouraging flow. One of the great strengths of pair programming is that the navigator is often not in the state of flow. In fact, the navigator is often interruptible and can respond to outside demands while the driver carries on with the current task uninterrupted.
I often tell people that good pair programming is incredibly taxing. It’s actually important to remember to take breaks. Often I find that I will go an entire morning without looking at my email or doing anything other than concentrating on programming. Several of us use the Pomodoro Technique to ensure that we take a break at regular times. Even so, I am grateful for XP’s Sustainable Pace, because by the end of the day, I’m finished and not fit for programming any more.
As I said earlier, good pair programming is very difficult. I find that it can take up to 6 months for a team to learn to do it well. Even then, it is quite easy to find ways to improve your skills dramatically after that. If you would like to learn pair programming, the most important thing is to stick with it and practice. Coding Dojos are a great way to meet experienced people who can show you pair programming. There are coding dojos in many countries and it is worth seeking them out. Even if you can’t do pair programming on a regular basis in your day job, setting up a coding dojo for practice can help you develop your pair programming skills.