Saturday, January 31, 2009

Why don't I pair more?

I've been watching a video of the hashrocket guys just now that Corey Haines twittered about. I've been amazed and inspired by Corey's pair programming tour: talk about turning lemons into lemonade. What an awesome idea. I've paired with Corey on some open source stuff at conferences, so I naturally wanted to get in on his tour. As a result I had the good fortune to have Corey stay with me on his tour. Unfortunately the timing of his stop happened on a day I had to spend dealing with client issues and didn't get to spend time pairing with him. And this leads into my topic: Why don't I pair more?

This isn't another post about why pair programming doesn't work, isn't a good idea, or any other such nonsense. I'm a true believer in pair programming. I've been sold on the concept since I first read about it in the first edition of Kent Beck's Extreme Programming late in the prior millenium. I've experienced pair programming and so I know the benefits first hand:
  • It consistently produces the best code, the code I'm proudest of in my entire career. And not a little prouder of. I mean, like, an order of magnitude more proud of.
  • I'm operating at about twice the velocity I would normally, which is a rush, and incidentally, means there is no negative effect on team velocity. I've actually measured this on a real project.
  • I learn way more
  • I enjoy my job way more
And on an on. But that's not what I actually want to talk about. This post is a way for me to put down in writing the reasons that I don't pair nearly as much as I want to. I'm doing this chiefly as an exercise so I can better understand the issues and change them. If it helps someone else, hey, that's pure bonus. The first few are about me. Which is good news, because it means I can change them.

  1. Part of me is afraid to
    I'll just go ahead and lead with this one since it's the hardest to talk about. I really like how the hashrocket guy put it: "Pairing is a burning crucible". Heat reveals impurities and exposes the true nature of things. If I'm having a self-doubting, insecure kind of day, I might not want this. Intellectually I'm totally convinced this is BS and the benefits far outweigh the minor pain of revealing what's obvious to everyone: I don't know everything. I like to think this reason is not a major factor preventing me from pairing, but in the interest of self-disclosure I'm putting it out there.
  2. But I might not get my stuff done
    This one is a bit more insidious, but like the prior reason begins with self-centered fear. If I pair on your task, I might not get mine done. And conversely if you help me you might not get yours done. There are at least two ways to address this. The first is to get over it: I believe that the software I produce will be way better if I pair. And obviously producing better software is what's best for me and whoever I work for. I have to be clear on this and act on it, which in my experience is not always easy. And of course the other members of my team do as well.
    The other way to fix this is organizationally: don't assign tasks to individuals. I've been in situations where this was out of my control. Some clients like having a single "go to" person for a given feature or issue. But this doesn't have to stop pair programming if the team doesn't let it.
  3. Inertia
    This one is a little more nebulous but I don't think it's less real. Sometimes I don't pair because I don't put forth enough effort to find someone to pair with. Other times I might be "in the middle of something". Either of these fall into the same general category of inertia: an object at rest (me, by myself, in front of my computer) tends to stay at rest.
The next few are harder to change, because they are about other people. Obviously I can't pair program if no one will pair with me. And no matter how much I would like to and am sure I know what's best for them, I can't actually control other people. But I'm going to list these issues anyways in the hopes that solutions will become clearer if we understand the problems.

  1. Odd number of people on your team
    This is so obvious an issue it seems silly to put down, but I've seen it make a big impact. I know the song says "One is the loneliest number" but three is also not very good. What tends to happen is pairing becomes awkward as one gal or guy is left out and sometimes leads to little or no pairing at all. I suppose you could address this by making a pair your smallest unit of staffing a project. But it's also true that even if you have 3 people on your team you could still pair 2/3 of the time if you are intentional about it.
  2. Distributed team
    Remote pair programming is a whole nother topic and I have some experience with it that perhaps I'll share in another post. Suffice to say: it's not as good as pairing in person, but better than not pairing at all. Because there are some technical details to work out and do, there is that much more barrier to overcome and it requires even more sustained effort to keep up.
  3. They won't let me
    This is supposed to be the elephant in the room: management won't let me pair program. My thinking is that this one is mostly a myth. I've worked in a lot of places, some of them quite draconian. The truth however is that pair programming can start so innocuously that it's hard to have a mandate against it. Imagine management saying: you're not allowed to help other people. Even the pointiest of pointy haired bosses would see how stupid that is. I'm sure someone will comment that "No, that really does happen". Fine. I just don't think it's all that common. Most people, in my experience, actually do want to be useful and contribute something positive. They just may (wildly) disagree about how best to do so.
  4. They code in X and X sucks
    This one requires compromise, but can be a a positive sometimes if you let it. My first ruby project I got to pair with my friend Jim, a dedicated emacs guy. As a result I had to learn emacs, something which I probably wouldn't have decided to do if I hadn't see what a productive environment it is first hand. There are other times where I pair with someone and they use something and even after trying it I still think it sucks. In that situation I try to get them to always pair on my machine. Err, I mean, switch back and forth between each others machines in the interest of fairness ;)
  5. No one wants to pair (except me)
    Alas, this has been the hardest to solve. You can be fortunate enough to work for (or start) a company that mandates pair programming. Or else you can attempt to influence people. My only advice, based on experience, is that less is more. Don't talk about pair programming at all, just offer to help people. And then ask for help when you're stuck. I've sadly tried the approach of trying to convert people to pair programming, unit testing, or any other number of quite good ideas by incessantly talking to people about them. Don't do this.

7 comments:

Corey Haines said...

Great post, Chris.

I'm glad that I've been part of an inspiration (along with the Hashrocket guys) to get you to revisit why you don't pair. I run into a lot of people like you who 100% believe that pairing is the best way to program, but there are reasons that they don't. It is great to see you list out the reasons and also address solutions.

I'm definitely going to point people to this entry as a good way to dispel some myths and address some real concerns.

Jeff said...

Awesome post. I've experienced all of these highs and lows of pairing myself. In the right situation, I fully believe pairing is the best way to go, but I've also felt the pressure of having to pair when it wasn't right (for any of the good reasons you mentioned) so it needs to be taken on balance.

Very nice writeup.

Unknown said...

As a mostly solo developer, I've actually never pair programmed, though I am in full support and I am beginning to make some moves towards finding people to pair with.

One thing I always wondered about was the environment issue. I'm one of those types who gets frustrated if I feel like my environment is holding me back, and will stop whatever I'm doing to set up a comfortable environment. So I have been wondering if anybody has had any success pairing in a setup with two computers working on shared source code. I am willing to learn other editors etc. but there is something to be said for having a setup where anybody can jump right in and be productive. Any insights on that?

MysteryCoder said...

Jeff, I understand what you are saying but I've come to the realization that I err on the side of not pairing way more often than pairing too much. I also have seen tasks that I thought weren't a good fit for pairing and in hindsight seen that I would have come up with a better result had I been pairing. All this is convincing me I'd really rather err on the side of pairing too much, the downside seems much less.

Supaspoida my advice, for what it's worth, is to not let environment issues stop you from pairing though I know I've been guilty of it myself. When I get past it I can learn from other people who do things differently.

Unknown said...

Thanks for the reply. Just to be clear, the environment thing isn't holding me back, just something that I've wondered about. I started thinking about it while I was working on code that lived in a VM from an editor in a host OS. The main obstacle for me has been in the form of things I couldn't control, mainly the people I was working with not wanting to pair.

I'm actually planning on doing my own work/travel experience in the near future, working out of different cities every month or so, and will be looking to meet up with others into pairing along the way. The life of a solo developer gets pretty lonely, and I've missed my days of travel!

joelhelbling said...

Dude, I feel your pain. I basically believe that pair programming is helpful only in a limited set of situations; such as when you're programming a computer, or thinking about doing programming a computer. But it takes a concerted effort to make that happen on a day to day basis. In many environments/companies it doesn't just happen naturally.

Speaking of benefits, the benefits I've seen include: 1) I'm better at staying on task, 2) design decisions are made faster with less chance of reversal later, 3) refactoring is less daunting, and 4) you learn much more quickly. Just to name a few.

Unknown said...

Awesome post.Diablo 3 items I've experienced all of these highs and lows of pairing myself. In the right situation, I fully believe pairing is the best way to go, but I've also felt the pressure of having to pair when it wasn't rightCheapest wow gold (for any of the good reasons you mentioned) so it needs to be taken on balance.