When I was a kid growing up in the 1970s there was a television commercial for Alka-Seltzer where one guy is giving some other guy some scary-looking food and says, “Try it, you’ll like it.” That became the catchphrase for an entire generation and it meant not to pass judgment on something until you have experienced it for yourself.
Inevitably I find that people who think that pair programming is a bad idea have no experience doing it or they did it incorrectly, and so they had a bad experience with it. I’m not saying that pair programming is for everyone or for every task but very often pair programming represents an opportunity to learn, and that’s usually a good thing.
My posts sometimes appear on other websites and I know that whenever a post that I’ve written on pair programming shows up on one of the programmer websites that inevitably I will get a comment from one individual who will remain nameless here about what a stupid idea pair programming is. I guess it is a dumb idea to want to share knowledge and learn from each other. I mean, who would want to improve themselves as a developer? Who would want to learn new techniques for solving problems or gain other perspectives?
Wait a minute. I would.
And these are just a few of the things that I’ve learned recently from pairing with other software developers. Pair programming is the fastest technique that I know for sharing knowledge among the team. Pair programming is doing a code review as it’s being written. It can be amazingly productive and useful.
Pair programming can also be a nightmare if it’s done wrong. With the wrong expectations or without the basic skills needed to do pairing successfully, we put ourselves at a loss just like we would in any technical practice. You wouldn’t expect that you’d be able to do continuous integration or code refactoring without learning some techniques and the same thing is true with collaboration. We need to learn some basic techniques for pairing and mobbing so we can do it successfully.
It turns out that convincing software developers of the value of doing pair programming is quite easy. Just give them an experience of doing it that’s positive and they’ll usually see the value and want to do more of it. If you only tell them about it, no matter how good your description is, it’s not nearly as compelling as experiencing it for themselves and so I strongly encourage developers to try it but first learn some basic techniques on being able to do it well or else you could fall into the trap of thinking that you’re doing pair programming when you’re actually just taking turns at the computer. Pairing is something much more than that so check out the rest of the posts in this series for more information on how to do pair programming well.
If you’re a manager who is skeptical about pair programming then I have to admit that you’re a bit more challenging to convince. Remember, the goal is not for developers to produce a lot of code. The goal is for developers to produce a lot of good code and very often they need to discover together what good code means. When we begin to recognize that the real bottlenecks in software development are not typing but rather understanding and interpreting requirements as well as debugging code and that both of these activities can be accomplished much more efficiently and effectively when pairing, then we can start to realize how pair programming can be a big time-saver as well as providing all of the other benefits we’ve discussed.
But this isn’t something that you can force the team to do and very often managers who try to force their developers to pair without the team’s agreement that it’s a practice they want to explore, end up getting a revolt on their hands. The best ways that I found to introduced teams to pair programming is to simply give them an experience of doing it. Maybe set up a practice time and do a code kata in pairs or take a challenging problem you’re working on and work through it with a colleague in a pair and to get the most out of your pairing session, follow the guidelines I offer in my next six posts.
Note: This blog post is based on a section in my book, Beyond Legacy Code: Nine Practices to Extend the Life (and Value) of Your Software called Seven Strategies for Seven Strategies for Agile Infrastructure.
Previous Post: « Why Practice Four: Collaborate
Next Post: Engage Driver and Navigator »