Skip to main content

It's More Fun With Two: Pair programming done right

A couple of months ago, I blogged about some of the mechanics of pair programming.  This post is more about the attitudes around it and supporting practices.

Pair programming is often held up as the one true path to good code, but there are some dissenters.  Many of these people aren't naysayers, but instead believe that while pair programming has it's place, so does writing code in blessed solitude.  Some (at least anecdotally) think that pairing is the root of all evil.

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?
2 comments

Popular posts from this blog

Agile Performance Management: Why Performance Reviews Suck

Many thanks to Mary Poppendieck, who wrote about this topic in 2004, and proposed a comprehensive solution.  She is the inspiration for much of my thinking on this subject.  She is also a better writer than I am a cartoonist.


Performance reviews suck.  I don't know of anyone who goes into their appraisal without some trepidation.  Your boss is guaranteed spring some surprise criticism on you that is ill-informed or misses the point as you see it.  It's a real challenge not to get defensive about that.

The only thing that makes your own performance review suck less is having to give them.  As a manager, I have dished out quite a few, and some of them went pretty badly.  (To the people at my first management job: Thanks for helping me learn how to get better at them.  Your sacrifice was not in vain.)  Since then, receiving one isn't nearly as gut-wrenching, if only because I try to make it easier for the guy on the other side of the desk.  I've been there, and I know how …

Do. Not. Optimize.

You've probably heard this quote before:
Premature optimization is the root of all evil.
 - Tony Hoare
Speculative optimization is always wasted time.  In the absence of an actual performance problem, you're just burning time that could be better spent on refactoring your code to make it clearer.  This is exacerbated because performance-optimized code is usually harder to read than code which hasn't received such treatment.

Here is what you're doing when you optimize:
Adding code that now must be maintained.Obfuscating the existing code.Spending time writing code that doesn't add value. But what's that you say?  You have the experience and know-how to decide when optimization is needed?  Maybe, but probably not.   The people at Sun and Oracle may or may not be smarter than  you or me, but they certainly know more about optimizing Java bytecode than we do.

For example, some people think that having a large number of classes is slower than the alternative.  This …

Developer Skills: Drawing

You aren't a good developer if you can't draw. Fortunately, if you're a human, you can.  Drawing isn't an inborn talent, it's a technical skill that can be learned.  Write the previous sentence on a piece of paper to prove it to yourself.



There.  You just drew a whole bunch of letters quickly and (hopefully) legibly.  Words are a complex set of shapes that need to be drawn in a particular sequence to have meaning.  It's the same basic skill you use when drawing non-character shapes.

Drawing isn't a binary skill that you either have or do not have.  It's a continuum, and even at the shallow end (people with barely-legible handwriting), you have enough of it to communicate ideas visually.

So that changes the top line of this post to:
You aren't a good developer if you don't draw. Visual communication is much more powerful than text.  (This study found 65% retention over 3 days for images vs text.)  We also absorb visual information much faster th…