Paired Programming - Who? What? When? Where? Why? and How? . . .

Cheese Pairing for this Post: blue stilton
[ugh. much like the meeting, this cheese leaves me irritated and with a slight taste of vomit in my mouth that I can't seem to shake for the rest of the day]

So the other day at work, we had a meeting to discuss Paired Programming. The Outlook invite said something about "Improving Paired Programming," but from the time we started, it felt a lot more like "Bitching about Paired Programming." At one point, while we were listing a few things we like about it, one of our managers actually said, "Let's stop giving text book answers and talk about the real world." As I am a huge fan of the technique, I have to vent/rant a little and get my opinions out there.

What (is Paired Programming)?
Just so we are on the same page, allow me to assert some preconditions for the follow discussion. When I say paired programming, I am talking about 2 developers, 1 computer, 1 story/bug/issue to work on. I prefer to have 2 keyboards and 2 mice as well, but that is a matter of personal taste and I can understand why some people prefer to only have one of each. Anyway, that is it. That is all I am talking about. Two programmers, one driving, one navigating (when done properly) or sleeping (when not done properly).

Why (do Paired Programming)?
This is the big one, eh? For those of us who have been doing it for a while, it seems like a no brainer, but let's review for the heck of it.

1. Let's start with the reason that is least important. We have a business requirement that all production code be reviewed before going to QA and paired programming satisfies that requirement. I called this the least important reason why to do paired programming, but it is actually pretty significant. The alternative is that we perform code reviews after the code has been written. Scientific studies (I read a couple somewhere. . . .you have google, you find 'em) as well as lots of personal, anecdotal evidence prove to me that code reviews after the fact are a less effective way of preventing faults from reaching QA. Time is always a constraint during a review. How many minutes does it take to properly cover all the enhancements, refactorings and reasons behind them that went into 35 hours of work in the last week? And who wants to take that time when they have their own 35 hours of work to get done? If it compiles and passes the tests that the developer wrote for it, that has often been enough to pass any code reviews I have seen. And, since we already mentioned time constraints, if the review happens at the end of the cycle, and the reviewer(s) see an architectural or design flaw, do they mention it? Do you just let it go to get the feature out and add that to the technical debt pile? Do you throw it back to the developer, or another developer, to rework it for the next iteration? These types of issues are reduced when you have 2 sets of eyes on the thing throughout.
   
2. Two heads are better than one! I just touched on this a little, but let's face it; two developers looking at the same issue are going to come up with a better design/solution than one developer. If they see the solution differently, they can discuss it and come up with something better than either would have done alone. Even if they have the same solution, that at the least is confirmation that it is a workable one.
3. It is less likely that 2 people are going to break the rules than one alone. Let's be honest, how many times have you been under a deadline and, even though you know that you need to test, and you are totally committed to working test driven and then you hit up against some legacy code that is just not designed for testability, and you just say, "Screw it, I don't have time to do this right! Add it to the technical debt. QA will do integration testing on this anyway, right?" If your pair is sitting there, you will probably just man up and do it, right? Another flavor of this is coding standards. If your company uses one that isn't the same as you use at home, you may just slip into your own habits. A pair is going to say, "What are you doing?" before you get to the second private field without an underscore. I've tried, honest, but I'm just not feeling that underscore, guys.
4. This is a simple one, but important. That second set of eyes is going to notice your goofs quicker than you are. If you are really in the groove and you instantiate a CardProcessor where you needed a CartProcessor, a pair who is awake will take away the keyboard and call you a moron or at the very least ask you why you are doing it. Even when it isn't a logic flaw, but just something that the compiler or the tests will catch, it is still quicker to get it before that, eh?
5. Here is a BIG one: Training. None of us knows everything. I know, that hurts to hear, huh? Well, I said it so I think I may need a Vicodin. But let's face it, there are so many things to know from CSS, JQuery, ASP.NET, C#, T-SQL, TDD, not to mention the Domain itself, that having someone there who may have more experience in at least part of one of these areas can be a big benefit. The good thing about it is that you can just ask them right there and then you own the knowledge too. You don't have to go in search of that-one-guy-who-works-wierd-hours-and-lives-in-a-cave-and-drinks-too-much-Monster and admit to him that you don't know why the subprocessor written in assembly when you were 3 years old is returning a certain value when you pass it the following parameters. Your pair has that knowledge already. . . .or at least he has your back when you are in the C-monster's lair.
   

In summary, the whys include: Cause I said so!, Code Reviews Suck, 2 Big Brains > 1 Big Brain, Standards, You Can't Type, It's Not a Ubiquitous Language if Only One Person Speaks It.

How (should you Pair)?
There are lots of ways. Just do it comes to mind. Recommendations I have are as follows:

1. Change pairs often! Daily ought to be enough. Twice a day if you work 4-Tens (lucky jerk). This rule applies even when you are working on a multiday story. I would say even especially when it is a long story. I would put 2 guys on it on day 1, take one of those guys off on day 2 and replace him with someone else. On day 3, take the remaining guy from day 1 off and replace him. There are several advantages to this. Getting stale means getting sloppy. Bringing on the new guy means explaining what you did. This will probably happen pretty quickly. . . .Unless he asks you, "Uh, are you high? Why did you do it like that?" Then you get to hear his solution. Between where you were and where he thinks you should be, you may find a better solution. Good thing he showed up on day 2, rather than day 25, huh?
2. Also, change pairs often! You know that one guy you can't stand? Working with him all week could make you even crazier than you already are, eh? It is worth noting that you are that guy, at least to one member of your team.
3. Team Leads ought to select the pairs. Or at least be involved. The reason for this is that, given the option, we are most likely to just work with our friends every day. Let me tell you, that is fun. Also, it is fairly inefficient when it comes to knowledge transfer. Team leads ought to be making pairing assignments based on some overall plan for the team. Certain members may be weak in some areas and should be paired with those who are stronger in those areas to bring them up to speed. They also may chose to pair a couple of seniors together on particularly challenging issues, at least for the initial design. There may also be some constraints, such as one on our team that states that a pair may not consist entirely of contractors. Assigning the pairs will also cause more mixing and this can help the team members become closer and make communication easier and more open.
   
4. When pairing, the more knowledgeable member should be the one navigating and writing the tests. By having the guy who knows what is going on write the tests, he can make sure they are correct, and he can also explain to the other guy the why it needs to be done in a certain way. This means that you will be changing drivers often. Coder A writes a little test, Coder B writes a little code. Repeat. When you are of equal knowledge on the subject, just mix it up. A writes a test. B implements it. B writes the next test. A implements it. Repeat. By swapping drivers often, you make sure that you are both involved.
5. Ask Questions! This shouldn't even need to be said, but it does. Whether you are the junior pair, senior pair, new guy on the team, expert with 20 years experience, it doesn't matter. That guy sitting next to you knows something you don't. He may be using a hotkey you don't know, or possibly a design pattern you aren't familiar with. Big or small, he has some knowledge you need, and you need to ask him for it. Don't be afraid to ask for it.

In summary, the hows include: Change Pairs, Change Drivers, Ask Questions.

When (should you Pair)?
This depends on your environment. I say, as much as possible. At the very least, for everything that is going into production. For us, we start pairing right after Morning Standup and pair until the end of the day. Since this is about 7 hours for us, that means only 35 hours a week of pairing. I heard some of the guys whining about how they never get a chance to do any personal research on the domain, tools, etc, and I gotta say, that is pretty weak, 'cause we really are supposed to work 40+ hours a week. Since all of our meetings fall inside the pairing hours, it seems like there are at least 5 hours a week when you could be doing personal research, or writing more tests (as long as you aren't writing any production code), or asking questions, or whatever. Do you need a list of things to research that you may not be an expert on? Start here: .NET 3.5 framework, ASP.NET, Ajax, JQuery, CSS, C#, TSQL, NAnt, CruiseControl.NET, TDD, NUnit, RhinoMocks, WatiN, ReSharper (and its plugins), TFS, Better source control than TFS (why can't we all just use SVN?), GoF Patterns, Patterns of Enterprise Architecture, Inversion of Control and the Dependency Injection Pattern, .NET MVC framework, Linq, MFP, MFC, MVP, Our Domain. If you are an expert on all that, you are hired 'cause we don't have one on staff. On second thought, you are not hired, cause you are lying. And if you aren't lying, and you really are an expert on all that, we can't afford you. Anyway, there is a lot to learn and you don't need to pair to do it.

Where (should you Pair)?
I think you ought to pair in the same room with the rest of the team. This allows for easier communication and greater camaraderie. You know how you don't know everything? (Sorry to bring that up again) Well, your pairing partner doesn't either, so it might help if you don't have to go trekking around to find the guy who does. I know that this doesn't work in every environment, but if you can do it, I think you should.

Who (should Pair)?

1. Simple. Everyone who is working on production code.
2. Teams who want to make high quality software quickly, with few defects.
   
3. Also, everyone who wants to learn from another member of the team.
4. Anyone who thinks they know something worth teaching to another member of the team.
5. Umm, if you aren't in one of those categories, do you even have source code access? Please say no.

Summary
Paired programming is an excellent methodology if you want to create a software package that is maintainable. Done right, it enhances the quality and the velocity of software development.

Well, there's my ten cents, my two cents is free. . .

Sorry. If you made it this far, you didn't deserve an Eminem quote. I really do apologize.