Pair Programming: My Personal Nightmare(bennorthrop.com)
bennorthrop.com
Pair Programming: My Personal Nightmare
http://www.bennorthrop.com/Essays/2013/pair-programming-my-personal-nightmare.php
1 comments
For some (many?, most?) people pairing is just too intrusive, makes them uneasy, makes them nervous and, thus, less productive.
No amount of productivity metrics can overcome this drawback. I'm not particularly introverted, but the same moment someone tries to force me to do pair programming for longer that few minutes a day at the time convenient to me, I would start looking for another job. What's next? Trying to feed me with energy drinks to make me more durable/productive? Or giving me drugs to make me more creative/productive? Thanks, but no thanks.
No amount of productivity metrics can overcome this drawback. I'm not particularly introverted, but the same moment someone tries to force me to do pair programming for longer that few minutes a day at the time convenient to me, I would start looking for another job. What's next? Trying to feed me with energy drinks to make me more durable/productive? Or giving me drugs to make me more creative/productive? Thanks, but no thanks.
I worked in a pair programming shop for nine years. What I saw was that some programmers couldn't handle it at all (you're probably one of them), but others took to it like a fish to water. I can go either way myself.
But again, it's not about the productivity of the individual. It's about the productivity of the organization. If I put on a manager hat and one programmer can't deal with team processes, no matter how good she is, she's gone. If I want the benefits of pairing for a team, I won't hire programmers or keep programmers who can't deal with it.
But again, it's not about the productivity of the individual. It's about the productivity of the organization. If I put on a manager hat and one programmer can't deal with team processes, no matter how good she is, she's gone. If I want the benefits of pairing for a team, I won't hire programmers or keep programmers who can't deal with it.
First, don't place isolated works of genius against the mundane day-to-day work that most people do. Most of us aren't geniuses. I'm not an Einstein, and I'll never look good compared to him.
Next, I don't think it's that vociferous a demand in the industry. Most of the industry still resists pairing, regardless of results. And certainly, nobody is saying that it's impossible to be productive unless you pair.
Now, some positives for pairing. First, it's a risk management approach. Businesses generally aren't interested in maximizing productivity. They're interested in minimizing risk. Don't believe when they say otherwise, they're full of crap. (To be precise, they're interested in minimizing the APPEARANCE of risk more so than risk itself, but.) Depending too much on the results of individual programmers who could quit, be incompetent, or get hit by a bus is a business risk. By pairing, the knowledge gets distributed throughout the team. Moreover, it helps mentor junior programmers and integrate new staff.
Beyond that, I just find it a useful technique in many situations. Programming requires thinking on several levels at once. I've found it very effective for the driver to focus on the individual lines of code, while the kibbitzer keeps track of the big picture. It also helps keep you going when you hit a roadblock, rather than checking Twitter and coming back to life two hours later. So there are real productivity gains to be had.
Have you ever seriously TRIED pairing?