I’ve never liked the idea of pair programming. I was involved with it once, and it was a complete cluster [expletive deleted]. But even ignoring those experiences, I still have a visceral reaction to hearing the words “pair programming”. It wasn’t until I read a blog titled “50 Strategies For Making Yourself Work” that it dawned on me. It was the following quote:
You’ll be less likely to slack off if someone else is counting on you to perform.
What’s interesting is that this wasn’t an article about pair programing; it didn’t even have anything to do with software development. But as I read this, I had the mental image of somebody standing over my shoulder, watching every little thing I did. I don’t work well in that situation. Yes, performance anxiety. Things that would have taken me five minutes to complete would then become ten.
I think the visceral reaction comes from the lack of trust that pair programming communicates. “You’ll be less likely to slack off if someone else is counting on you to perform” means “you cannot be trusted to work on your own, so we’re going to set someone right beside you and have them watch your every move.” In my mind, knowing that someone is depending upon me to get something to them by the end of the day is all I need to get things done; I don’t need someone to watch over me as I do it. If knowing someone depends upon your work doesn’t keep you from slacking off, why would someone staring over your shoulder?
What are the other reasons?
- You’ll have to have a 100% increase in productivity just to break even. Because there will now be two people doing the work of one, that “work unit” will need to become 100% more productive. While I do see some productivity increases in pairing (for example, catching the mistake of using a = instead of a ==, or other similar ‘typo’ bugs), but I cannot imagine how paring would double productivity. And if the pair does manage to double their productivity, that’s just breaking even. No benefit.
- You lose your individuality. You’re now basically working with a punch clock, given that you have to coordinate your time with your pair. Let’s say you’re used to varying your commute time based upon traffic conditions. No more, now that you have to arrive (and leave) with your pair. Need to duck out to see your kid’s school play, go to the doctor, just get out of the office for a while and grab a coffee. Nope, no way, nada. You’ve become a sycophant in the corporate rat race. Yes, the people you use to laugh at. Now you’re one of them, thanks to pairing.
- With the loss of individuality comes the loss of creativity. Having a pair will impact your trial-and-error process (because nobody likes to have people watch their failures, and trial-and-error is more error than anything else), as well as the time you just need to sit there and think something out. Yes, sometimes a pair will be useful when thinking something (particularly with the hard stuff), but most of the time it isn’t.
- Interrupaloosa! You’ve managed to figure something out, you’re typing away wildly, your hands barely keeping up with your thought process when: “Um, hey, wait. What does that do?” says your pair. The sound you hear are the boxcars of your thought process being crushed as the train flies off the tracks. Interruptions from the general business day are bad enough, but when you’re joined at the hip by an endless stream of interruptions, you’re productivity is going to plummet. Just like your train of thought goes rolling end over end down the steep canyon.
So there you go. There are my reasons for not liking pair programming. I’m standing by, awaiting the Agile police to come and take me away for having the audacity to doubt The One True Methodology.
