The Seven Myths of Pair Programming

I am lucky that I work for a company that embraces XP. Moreover, there are lots of interesting books on the shelf in our office bookshelf; books about XP, Java, Software Engineering and many more.

Last night, I started reading Pair Programming Illuminated written by Laurie Williams and Robert Kessler. It is quite easy reading and I will share my opinions about XP with you as do through the book over time. Today:

The Seven Myths of Pair Programming

1. It will double the workload with two doing the work one can do

In fact it lowers it. Two can produce a better quality code in less time and less time is spent debugging later as well. Need to say more?


2. I'll never get to work alone. I couldn't stand that!

Nonsense! You'll never spend 100% time pair programming a day. In most cases the "alone time" ranges from 25% to 50% a day. Pair programming is intense. We need to have breaks from pairing. During those we get to do stuff that you got to do, but it'd be a waste of time if done in pairs - like checking and responding to your e-mails. If you want to do some programming alone, then pick something simple. Leave the heavy stuff for pair programming.


3. It will work well only width the right partner

Again, we think that there is the "right" partner, but as we realize that we all are different and work differently, we can influence each other in many ways. Thanks to pair programming I got closer to many people in the team and feel more comfortable working with them. I feel being part of the team. Pair programming enhances the feeling of trust and improves the teamwork.


4. Pair programming is good for training. But, once you know what you're doing, it's a waste of time

Not necessarily true. It's a great way for knowledge transfer. I started working on my current project much later than my peers. Pair programming with them gave me a real boost in getting my head around the application and frameworks used. Pair programming can be looked at as never ending learning where we all learn from one another, not necessarily realizing the teaching part.


5. I'll never get credit for doing anything I'll have to share all recognition with my partner

Who cares! This is teamwork, forget your ego! Thanks to pair programming I feel stupid every day. In a good way, that is. I know I learnt a lot and I did a good job every day. You know how much you learnt and your partner will tell you if you did a great job. Don't be shy, do the same for him/her. Besides, you can develop an approach of task ownership. You pick and own the task. Then you "recruit" a partner to pair on that task with. Still there is no code ownership and you can get credit for the task well managed and done.


6. The navigator fins only syntax mistakes. How boring is that! Compilers can do that better than humans can any way

Navigator usually has the time to focus on the problem on a larger scale or consider various cases or scenarios while the driver works and concentrates on the particular one the pair is solving. This approach shortens the time - one, after finishing a step, would have to stop and think about the next step before continuing. Two, on the other hand, can work in a "flow" and maintain a steady pace.


7. The only time I ever get any real work done is when I'm alone. Now, Ill never get anything done! Pair programming would drive me crazy!

Well, pair programming is a different way. You can't get into the "flow" as described in Peopleware : Productive Projects and Teams written by Tom Demarco and Timothy Lister. But on the brighter side, if you develop in pair it does not take you 15 minutes to get back to the "pair flow" when interrupted. Plus, when people see you are busy, they are less likely to interrupt you anyway.

Pair programming has only one drawback for me so far. I don't get to listen to my MP3 collection that much, well almost at all. All that joy is left for my little home projects I work on just by myself.