The truth isn't somewhere in between. Pair programming really is coding nirvana, but only if you do it right.
Keys to Success
I have spent the last three years in a software development organization that has strong values around pair programming (after spending 20 years in 23 other organizations that didn't). It is pretty consistent - most of the seven teams practice nearly 100% pair programming. Most are pretty good at it. Some are awesome at it. In my experience, the following keys are what allowed them to reach levels of never-before-seen awesomeness:
- People - you have to eliminate assholes from the organization. If you have developers who belittle or bully other developers, they will destroy your ability to make this work.
- Frequency - you have to do it a lot. By "do it", I mean pairing pretty much all of the time, and swapping pairs daily or almost daily. (Some people advocate swapping even more often, but I don't have direct experience with that practice - yet.) Do this for at least 2 months before allowing any solo work. You simply can't get good at it unless you have a lot of practice.
- Urgency - build and maintain a sense of urgency across the team. All of the developers should be motivated to get stories all-the-way to done as soon as they can, with zero defects.
- Communication - pairs should be constantly discussing, whiteboarding, and calling over a product owner (or proxy) to clarify details.
Benefits
I'll assume for the moment that your organization doesn't practice pair programming, or does so only on a part-time basis. Why should you go to the trouble? What will you get out of it?
First of all, there are some sound psychological reasons. From a programmer's perspective, it is just plain more fun to work with a pair all day. You keep each other honest, which means that you never go home at the end of the day feeling like you haven't accomplished much. Productivity really is its own reward. It's hard to overstate the profound impact of going home at the end of the day - almost every day, with a sense of accomplishment.
It also feeds our social needs. You spend the day in a relaxed conversation (and occasional heated debate), talking about something you both enjoy and understand. How often do you spend 6 or more hours talking to your significant other about something you're both into? Once the team has been together a while, you'll also get a sense of camaraderie, as well as building up a lot of inside jokes. I haven't worked at many jobs where I felt as close to my coworkers as I have on projects were we constantly pair. (This is also a good reason to look for a sense of humor when you interview people.)
Finally, there are a number of excellent business reasons. Here is a logic-chain for you to consider:
- When developers are committed to pairing and feel the need to work fast, they work harder to understand each other.
- To help understand each other, developers usually draw pictures on a whiteboard or paper.
- When people communicate visually as well as verbally, they understand what the other person intends to do much better.
- When people understand each other's intentions and plans really well, they can point out flaws, solutions to the flaws, and additional opportunities for improvement much more quickly and effectively.
- When developers are communicating quickly and effectively, you get the benefit of two programmers' experience in a fraction of the time, with almost no software defects.
This means high-quality code done quickly. There aren't too many customers who would say no to that.
Pitfalls and objections
Of course, no plan ever survives contact with the real world. There are a lot of things that you have to adapt to. Here are a few of the problems I have seen and their solutions.
Problem:
How do you get a team to feel a sense of urgency, communicate a lot and pair all of the time?
Solution:
Tell them what you want them to do and why. Coach them to do it. It's simple, though not easy. Hire an agile coach or two if you can't do it yourself. And remove any jerks from the team. (Like I said, simple, but not easy.)
Problem:
Noise! Isn't it really distracting to work in an environment with constant chatter and movement?
Solution:
This one mostly solves itself. You'll be amazed at what people can adapt to. If the acoustics in your space really suck, look into some sound absorbing ceiling tiles and baffles. They can make a pretty big difference.
Problem:
The developers on my team just aren't committed to this. They're not jerks about it, they just don't believe in it.
Solution:
This is one of the most difficult problems, and probably the most common. The only answer that I have seen work is to have the committed people significantly outnumber the non-comitted people. Culture tends to follow the majority. If you have to, start with a small seed team and outnumber them with some contractors with the right outlook and skills, then slowly (every month or so) add another person to the team. When it gets large enough, fission the team into two teams and repeat. This is expensive, but worth it.
Problem:
There really are some things that are best done solo. How can I tell my team that they have to pair on them when common sense dictates that it's more efficient to split them up?
Solution:
There are probably far fewer thinks that are better done un-paired than you think. Enforced pairing at the outset helps the team identify more clearly what they are. Just tell them that - they'll probably get it! Give them a time-frame if you must, but it should be no less than 2 months. After that, he more obvious things like fixing simple UI bugs can be done solo… though if you're doing it right, you may find that you don't have any UI bugs, simple or otherwise. I'm just sayin'...
Problem:
I can't sell this to my business. They'll never let us do it!
Solution:
How hard have you tried? Can you enlist some help in selling the idea to them? Just as important - do you really need their permission, or will your boss (or his/her boss) provide enough air cover to let you get it done? If not, maybe your business is filled with
jerks and you should just find another job. I have worked in automotive companies before and I feel your pain.
Summing it up
Pair programming really isn't just the best way to get a project done quickly, it's also the most fun. Most programming shops don't practice pairing because they haven't tried doing it without understanding the keys to success or the challenges they were likely to encounter, then came to the conclusion that "pair programming doesn't work".
Doing it right really is simple: stress communication and urgency, and insist that your developers pair 100% of the time until they get good at it. It's a winning formula.
Discussion Question
What other problems could derail implementing pair programming in your shop?
