Paired Programming Part 1

The company I work for has decided to try out a more XP approach to programming. We use a lot of XP and Agile techniques already, but they feel it's time to bring it all together, and go to paired programming.

I'm going to blog about this process, because I think it will help me, and might help other people out there too. I don't think they'll mind - I generally don't blog about work, but I'll make sure not to mention them by name, give away any company secrets, or get too much into specifics.

Okay. So to start with, I'm sceptical. I don't see how it will work. The only thing that gives me hope is that the guy in charge of this did it for 2 or so years and says it works great.

So I'm negative, but I don't want to just slam it down. It has been done, and it has been successful, and just because I don't see how it can work doesn't mean it can't work. But not only do I not see how it will work, I don't want to do it. I can see the benefits to the company, and in theory, to an extent, the benefits to developers. But I see huge problems as well, on a developer level. These kinda fall into two categories: practical issues, and development issues. Now maybe some of these have been solved by other teams doing this kind of thing, but these are the issues I see looming.

So let's look at the practical issues. Some may seem silly, but remember that you spend the majority of your waking life at work, so it has to be an environment that you're happy with.

• Synchronising work times. You and your partner have to work the same hours. You have to have coffee breaks at the same times. You have to have the same lunch times. You have to have bathroom breaks at the same times. And all these breaks have to last the same amount of time for both of you.
• No personal business. Since every time you do something personal, you're holding up the other person. No phone calls. No browsing. No msn/googletalk/whatever. No email. No email notifications, since you might not be using your PC. And while this might seem like a good idea to management, distractions are useful. They keep us sane, and focused, and human, and in touch with the outside world.
  
• No snacking. Not only does it seem somewhat rude to have a biscuit or a chocolate without your partner having some, it's just not practical if you're both working. This can be difficult enough anyway; if you have to sync your lunchtimes too, it becomes really difficult. Get used to being hungry.
• No personal space. Now you're sharing a desk, you don't have your own desk. You don't have your little family photos. You don't have a space that's just yours. You probably get to use your own chair, but you won't necessarily be using your own keyboard.
• Physical arrangments. How do you arrange the desks? I hate sitting skew; I have to have the monitor right in front of me. How would that work? Where does the keyboard/mouse live? I have the monitor way closer than most people, and use a slightly bigger font, otherwise I can't see. How will that work? What if different people have different brightness/contrast on their monitors? Different lighting? Different keyboard shortcuts?
• No music. Can't listen to music on your headphones when you're working with a partner, can you?
  

And development issues:

• Who types?
• Will the non-typing person pay attention? And be able to follow what the typing person's doing?
• I hate typing with people watching - I end up making mistakes. Same goes for coding - I can do something fine on my own, but with someone watching I get flustered (this post explains it better than I can)
• I like to take time to internalise a new concept. I make notes that I never use again. How can I manage my learning process to match my partner's? And should I have to?
• I think better while I'm typing and writing code. I know that's not always right, and in a TDD approach you're supposed to do all that thinking first and coding becomes almost perfunctory thereafter. And maybe that's one of the 'benefits' of paired programming. But it's not how I work, and I don't think you have to do it that way to be a good developer.
  
• I don't want to spend all my time teaching my partner. And I don't want to spend all my time learning from my partner, and feeling like I don't have anything to contribute. Both are frustrating and boring.
• What if one partner (not me!) has a dominant personality? How do you prevent the other person being railroaded?
• How do you prevent the non-typing partner from switching off, either because they don't understand or just don't care? I've seen the quotes about people who've worked in pairs complaining that after that, when working alone, they felt like they only had a half a brain. But I feel that in a team, sometimes team members only bother to use half a brain, and relies on the other person to be doing the thinking.
• What if you get a personality clash? (It happens - no-one's fault, but it makes life unpleasant).
• I just don't like having to talk to someone for every little thing every minute of every day! (I've been reading a lot about XP, and I'm not going to post millions of links. But this one describes my reservations relating to this point really well).
  
• I'm not sure that productivity will increase. Each team now has to be twice as productive as an individual, during the same amount of time. Which means you have to do everything twice as fast.
• I understand the value of everyone knowing every part of the code. But I much prefer having areas of expertise - you have ownership of a bit, you can be proud of it, you feel of value to the team. Have a backup or two, of course - you don't want only one person to know the module, or you'll have problems if they get hit by a bus or leave. But let people feel that they have an area that they feel good about. I know, paired programming proponents will saw that the whole codebase becomes your area of expertise. But it's just not the same.
  

Communication is good. Collaboration is good. Redundancy (in terms of who knows how much of the code base) is good. A lot of Agile development is good. Working purely on your own sucks. But seeing as developers are often not the most socially adept of people (and I totally include myself in that), and for all the reasons above, I just don't think I can be 100% on board with this.

So while it may work, I don't think it's going to work for me. They're asking us to trust them, and try it for 2 or 3 months, and I'll give them that. It may turn out okay. And if there are any big problems, they're open to sorting them out. But I think going to work is going to get far more painful, fast.