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.


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.

How do you get a team to feel a sense of urgency, communicate a lot and pair all of the time?
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.)

Noise!  Isn't it really distracting to work in an environment with constant chatter and movement?
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.

The developers on my team just aren't committed to this.  They're not jerks about it, they just don't believe in it.
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.

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?
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'...

I can't sell this to my business.  They'll never let us do it!
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?

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 …

Windows 10 Driver Issue with Falcon / Z-77 Keyboard

Windows 10 has an issue with this mechanical keyboard (which works great, BTW).  It's a Chinese-made keyboard (aren't they all?), but it doesn't have much English-language support.

I captured a few screen shots of how to fix it in case someone else has the same problem.  (I got the instructions off of Tom's Hardware, but it doesn't have screen shots & isn't clear on some of the details.)

First, open up Device Manager and select the controller under USB controllers (not under keyboards).

Next, choose "update driver" from the Drivers tab.
Then choose the "browse" option (search doesn't find anything).
Then select "Let me pick from available drivers on my computer."
Finally, switch it from the ND device (which is the wrong one) to the generic USB compatible one (which works fine on my machine).

You might want to clip these instructions into your favorite notes software because:

You need to do this for each USB port you plug in…

Showing Off: How to Do a User Demo

Rather than repeating what has been said elsewhere, here is a nice short post on agile-for-all that covers the basics.

Here are a few things for my own future reference and teams that I'm working with...

Try to keep each demo to 5 minutes or less.   If it's longer than that, it's possible that you should be demoing more than one story.  More likely, you're just being too wordy.

TALK LOUDLY.   No, louder than that.  Louder.  Do you feel like you're yelling?  OK, that's about right.  You need to put your voice in public-address mode for 5 minutes.

Focus on why your audience should care about the story  This is particularly important for back-end work.  For example: Your story generates a feed of XML that will be consumed by another application. Show the output, and point to a couple of salient features in it.  Then be done.

The important part of the above is "show the output."  Showing the end users how to interact with your service is a separate sit-d…