Life After Pair Programming

When I first joined DRW I noticed that the vast majority of developers were not pair-programming. I was surprised that a company that employed so many smart people would just simply disregard a practice that I considered to be so obviously beneficial.

note: it's so easy to judge people who don't pair-program, isn't it? You can write-off their behavior for so many reasons:

• They simply haven't done it enough to see how much value it provides.
  
• They've used the wrong setup, and turned a positive ROI into a negative ROI situation in the past.
  
• They must be anti-social or not team players.
  
• They must guard their code because they are too proud or believe it's job security.

Never once did I consider that their behavior might be correct based on their context. There was no context in which pair-programming wasn't the right choice, right?

So, I did what any responsible employee who wants to help would do: I gave a presentation. I took pictures of a traditional (read: broken) pairing station setup - the setup where one employee looked over the shoulder of the person doing all the work. Then I took a picture of a dual monitor, dual keyboard, and dual mouse setup. I made the distinction between pairing and watching someone work. I explained how ping-pong-pair-programming worked. I think I said the right things, and the presentation was well received. Management was on board and offered to setup pairing stations for any developers in the company that wanted to give it a try.

A few people embraced it, but most went back to their traditional habits. I did manage to convert the guys on my team, and we paired the vast majority of the time.

Almost 3 years later, and on a different team, I basically never pair. In fact, when my lone teammate (and boss) asks if we should pair on something my initial reaction is always 'no'. The 2 of us are the only people working on the applications we support, and when we pair I often find myself very distracted and not really participating. Sometimes we ping-pong-pair and it keeps us both involved, but I don't feel like we're going faster than if I'd been working solo. Don't get me wrong, we sit directly next to each-other, talk constantly, and even look at code together at times when we're just starting to talk about a new problem. That level of collaboration feels beneficial, but actually coding the implementation together feels wasteful.

I know how I felt 3 years ago (when I joined DRW), and I know how I feel now. The fact that I've changed my tune so drastically made me think it was worth putting a few ideas on the web. I was also motivated a bit by the recent publication of Pair Programming Benefits. The Pair Programming Benefits article actually gives me a perfect starting place, by examining the benefits of pairing and how they apply to my context.

I feel like I can safely summarize the Team and System Benefits as: transfer of knowledge, superior quality, and collaboration. The Programmer Benefits can be summarized as: expansion of knowledge, truck factor reduction, superior quality, and team support. The Management/Project Management Benefits can be summarized as: aiding addition and removal of employees, knowledge transfer, and the ability to hire any skilled generalist.

So, our full list of benefits is: expansion and transfer of knowledge, superior quality, collaboration, truck factor reduction, team support, eased hiring and firing. I would agree with these benefits of pair-programming, which explains why I was such an avid believer in pairing in the past. However, if those pros don't apply to my situation then pair-programming becomes nothing more than using twice as many man hours to get the same amount of work done.

I'll start by addressing the easiest "benefits" that are effectively irrelevant for my team: eased hiring and firing and truck factor. Like I said before, my team size is 2. Mike and I are both very happy and there's almost no chance that either of us leave anytime soon. Even if we did choose to leave, we would give enough notice that someone could easily come in and replace us - and either one of us could support the applications on our own if necessary. The only real risk is that we both are killed at the same time - at which point it wouldn't matter if we paired or not. Statistically it's much more likely that only one of us would suffer something causing us to not be able to return to work, and as Chris Zuehlke (manager at DRW) once pointed out to me: if you build small, well written processes the time to understand or rewrite any software you know nothing about is small - often smaller than the cost of keeping 2 people informed on the details of the process. If I asked the stakeholders if we should use 2x as many man hours to ensure that we're covered in case one of us is suddenly killed they'd laugh at me - and I'd deserve it.

We're also not looking to add to our team, and if we decided we did want to grow I expect we wouldn't have any trouble finding someone who was looking for a well-paying job in manhattan using very cool technology.

The previous discussion was meant to address team size, but it also touches on "transfer of knowledge". Transfer of knowledge is valuable for teaching new techniques and enabling people to do maintenance. However, if little teaching is going on (often the case as Mike and I add features to an app we know fairly well, using technologies we know fairly well) and we both tend to do the maintenance on the code we previously wrote then "transfer of knowledge" is either not occurring anyway or is unnecessary. Also, on more than one occasion I've had to take a first look at some code Mike had recently written. It's always been straightforward and taken no more than an hour to dig-in, make, and test a change. Had we paired on everything he worked on I would have unquestionably spent far more than an hour here or there. Again, the ROI on knowledge transfer doesn't look good for our situation.

The "superior quality" benefit is an interesting one. I consider myself to be a good engineer who on occasion writes something beautiful. I like to share what's beautiful with everyone. This is something that's going to happen whether or not I pair (evidenced by my blogging). I know Mike does the same. I expect we're all proud of our most elegant solutions. However, more often than not I write fairly good software that isn't excitement provoking, but solves the problem at hand. I'm not sure anyone is benefiting from working with me at those moments. And, while it's possible that we'd get a slightly better solution if Mike & I paired, spending twice as many man hours for a 10% better solution doesn't seem like a great choice in the short term. In the long term those 10%s could add up, but what if I see the superior solution on my 2nd pass through and end up there while expanding a feature anyway? If I have a massive solution that might be a big cost. However, with small, focused processes I can tend to make a massive change to a process in ~4 hours. Delete is still my favorite refactoring and I do it as often as possible on my quests for superior solutions. Therefore, I don't believe those 10%s add up, I believe the 90% superior solution is often good enough or deleted.

I believe a few additional factors allow us to write code that is "good enough" on our own.

• The application is fairly mature and many of the core design decisions have already been made.
• Mike and I have Compatible Opinions on Software.
• Mike and I are at a similar skill level.

In my current situation I find that many of the tough decisions have already been made and I can follow the existing path. And, any decisions that I do need to make I usually end up choosing what Mike would choose and solving in a way that we both think is appropriate.

While I believe "expansion of knowledge" is often undervalued and under-practiced in our profession, I don't think pair-programming is the most effective way to expand your skills. Blogs, books, and presentations allow you to work at your own pace and dig in to your desired level. My experience pairing with people using tools or languages I don't know have been painful. I did learn things, but I couldn't help but feel like there were much more effective ways for me to get up to speed.

The final 2 benefits that I need to consider are "collaboration" and "team support". As I previously stated, Mike and I collaborate quite closely. We're always both happy to stop what we're doing to provide an opinion or direction. I honestly can't imagine a more collaborative environment. Basically the same thing can be said of "team support" - we constantly watch each-other's back. We're both looking to succeed and we know we need each-other to get to that goal, so it only makes sense that we look out for each other. We don't need pairing to force us to support each-other, the desire to succeed is more than enough.

When considering my context and the "benefits" of (or, in my situation, lack of benefits of) pair-programming, I'm no longer surprised that I basically never want to pair these days. Also, looking back at the other teams I was previously judging - their context back then looks a lot like my current context. With a bit more experience under my belt I have to say I'm honestly a bit embarrassed for never even considering that they already "got it" and were already making the right choice. Oh well, live and learn.

While it's easy for me to examine my situation and make a determination I think there is a more general context where these same ideas apply. The aspects of an environment where pairing may not be beneficial seem to look something like this:

• small team (< 4 people)
• small software (components/processes can be rewritten in < 2 days)
• motivated teammates
• talented and well-seasoned teammates (similar skill level, and skilled overall)
• the design of the application is fairly mature and stable
• all team members have compatible options on software

Thanks to Michael Feathers, Alexey Verkhovsky, Pat Kua, Jeremy Lightsmith, Lance Walton, Dan Worthington-Bodart, James Richardson, and John Hume for providing feedback on the initial draft of this entry.

Pairing isn't the Solution

In 2007 & 2008 I wrote several blog entires on Pair Programming (tagged with pair programming). Pair programming solved a lot of problems for me: knowledge transfer, mentoring, code review, etc. It also solved another problem at the same time, even though I wasn't aware of it. Pairing helps reduce the number of cooks in the kitchen.

These days I'm working on a project with some really talented people. The pace at which we deliver features is far faster than any project I worked on before I joined DRW. However, I've seen two effects of having so many talented developers on the same team: wiki coding and spork sharing. (both metaphors coined by my tech lead, badams)

Wiki coding occurs when the churn on a class or component is so great that whoever commits last ends up deciding what it should do. Wiki coding leads to inconsistent design and lack of convention. Spork sharing occurs when a fork is designed and a spoon is also needed. Instead of creating a spoon, you want to share the handle, so you create a spork instead. Now, you have no spoon or fork, you have a spork, and sporks suck if you really want a spoon or a fork. Both problems seem to stem from differing vision for the classes or components.

It appears that the more talented programmers you put on a team, the more fractured the vision for the project becomes. Of course, complexity (as well as many other factors) can also increase the fracture.

You won't catch me advocating for 'hard-working average programmers'. What I do believe is: you should stock your team with only rockstars, between 2 and 4 of them. I've worked on teams that only had 3 people. I've worked on teams with about 16. I was a consultant, I've worked on a lot of teams - big and small. My experience was that the smaller teams were much more effective, every time.

Reflecting on the past few years, I came up with the following reasons for keeping your teams small:

• New Technology: Small teams can more easily come to a decision to try a new technology. Also, if a small team selects a new technology, the entire team is likely to learn the new technology. However, an individual on a larger team may find a way to never learn the new technology and never contribute to that area of the code. Worse, a larger team may shy away from trying new technology because they cannot come to a consensus. New technology can offer productivity boosts, and missing those boosts can hurt a teams efficiency.
• Smaller Problems: Smaller teams generally implies solving smaller problems. Most problems can be broken down into smaller, less complex problems. Once the problem is broken down, it should be easier for the small teams to craft elegant solutions that can integrate to solve the larger business need.
• Improved Maintainability: Smaller teams generate less code, which allows all team members to have depth and breadth concerning a solution. Having depth and breadth allows you to easily share vision and fix broken windows.
• Ownership: Ownership isn't bad. Single points of failure are bad, but having a small team that feels ownership over an application will generally lead to higher quality and more emotional attachment to it's success.
• Context Switching: Smaller codebases maintained by small teams solving a smaller problem will context switch less, because there's nothing else to context switch to.
• Responsibility: The Bystander Effect applies to code (e.g. production bugs) as well.
• Unified Vision: In a large team it's easy to have an opposing vision and never be proven wrong. In a small team it's likely that you will agree on a vision for the project (process, technology, etc) as an entire team.
• Adding: Adding one more person to a 2 person team will likely result in a new productive team member relatively quickly. Smaller team, smaller problem, smaller codebase = easier team to join.

Sometimes I wonder if consultancies sell large teams, and then use pairing to make the large teams more effective. It's definitely my experience that large teams pairing are much more effective than large teams that aren't pairing. However, I wonder if anyone ever stopped to ask: would a smaller team have been sufficient (or, better)?

I still believe pairing is an answer to many problems. However, the best solution to making a 8 person team more effective isn't pairing. I believe that a superior solution is finding a way to solve the problem with a smaller, more effective team (or teams).

Is Distributed Development Viable

I've never seen distributed development succeed. However, before we get into what I've seen, I need to be specific about what I'm describing.

Distributed Development: A group of individuals who work across time, space, and organizational boundaries with links strengthened by webs of communication technology

The link above for Distributed Development redirects to Virtual Team. Wikipedia also has an entry for Distributed Development; however, I found the description of Virtual Team to be much closer to what our industry generally labels Distributed Development.

Just to be clear I'm not talking about outsourcing (subcontracting a process, such as product design or manufacturing, to a third-party company) or what you might call off-shoring.

This entry will be written with that in mind.

Take 1
Several years ago I worked with one of the nicest and most talented developers I expect I'll ever encounter: Badri. We worked together for about a month before he was forced back to India to deal with US visa issues. We knew this was going to happen and decided that it was so important to keep Badri on the project that we were going to give distributed development a shot. Badri knew the code, the team, and he was great on so many levels that the choice couldn't have been more obvious.

After just a few weeks, we gave up on distributed development. Ever since that experience, I've been highly skeptical of the feasibility of distributed development. I had actual experience working with one of the greatest developers I'd ever encountered, and we still failed.

Failure can be good. There are always lessons to be learned when you fail. Here were a few that I picked up from that project.

• Time difference is probably the single largest contributing factor to failure. Badri was in India, and we were in Deleware, USA. There was almost no time overlap to our workdays.
• Having the local or on-site developers feed requirements back to the off-site team equates to an order of magnitude efficiency loss.
• Having the on-site developers decide what pieces are going off-site quickly translates to the off-site team being pissed off about getting the boring work
• Businesses expect the same level of quality and productivity from the on-site members as the off-site members.

Given those circumstances, we definitely failed. Epic failed in fact. And, to make things worse, I was the one that had to tell Badri that we were going to give up on distributed development. Imaging having to tell someone you have nothing but admiration for that "it's just not working out". I still feel guilty about it to this day.

The time difference was a huge killer. Every time we spoke to Badri either he was half asleep or we were. I think Badri was working 12 hour days also, just so he could try to talk to us at the beginning and end of his day. It also meant no wine with dinner or having a bit of a buzz for the 11pm stand-up. Either of those options is unacceptable. Worse, if we didn't communicate what we needed in detail, the off-site team would be off in the wrong direction for up to 12 hours straight. We threw away several days worth of code because we hadn't given them enough detail to go in the right direction.

Truthfully, we (the on-site developers) shouldn't have been deciding what they were going to work on in the first place. It was a tough project and we were all learning. None of us felt like we had the time to do both the development required of us, plus the analysis required to give the off-site team good direction. Instead, the off-site team got minimal direction and delivered code that was of minimal use to us. It was beautiful code, but it wasn't what we needed. Again, epic fail.

Even though we clearly were not functioning well, the business expected that the off-site team deliver at the same pace as the on-site team. The business had met and loved Badri. No one could understand why our pace had suddenly dropped off. Not good. More on this later.

Take 2
A few years later I joined a project that was just beginning to give distributed development a shot. I hadn't been there 3 days and I was already in the CEO's office explaining why I thought it was a bad plan. Of course, I was gun-shy, so that was to be expected. Luckily, Fred George was also there and he was more optimistic. In the end we went to an on-site team, but Fred showed me that distributed development is possible.... maybe.... eventually.

We experienced several obstacles, and we overcame some. Again, there were plenty of lessons to be learned.

Time difference was less of a factor. This time I was working in London and the off-site team was in India. Our workdays overlapped fairly well. This was obviously a huge move in the right direction. We also collaborated on who would work on what, which helped ensure that everyone was happy with what they were working on. And, the analysis came from a BA that collaborated with both portions of the team. The BA even traveled to India occasionally.

However, things were still quite broken.

Some members of the team had never met other members of the team. There's something about working, collaborating with someone in person that is almost impossible to replicate over a phone or IM conversation. It wasn't that we didn't want to get everyone together, but there were visa issues that couldn't be overcome. It was a big mistake with no good resolution. Some long time team members couldn't travel, but if we replaced them with people who could travel we would lose domain knowledge and context.

Communication was a constant problem. The telephones on both ends presented problems. I have plenty of Indian friends that I have no problem understanding, but with the off-site team speaking into a bad connection and it being sent out of our bad connection, I caught every other sentence, if that. To make matters worse, people weren't talking nearly as often as they needed to be. We tried to address this by creating a chat room and mandating daily checkpoint phone calls. Both ideas were abandoned due to lack of buy-in. In the end we never did solve the communication issue -- in my opinion. I think the reality is that most programmers are introverted, and being off-site just gives you one more excuse for not talking to the business, even when you really should.

Connectivity was also an issue. If you're in the US, you don't really even think about the reliability of your internet connection. However, in many other places in the world connectivity is much less certain. There were several occasions where the off-site team was simply unable to check-in their code. We never did figure out if the problem was on their side, our side, in our vpn, or some other bizarre location. If your off-site can't check in, IM you, or get to the wiki, you obviously lose productivity.

There was one common problem: the business expected the same level of productivity from both teams. I'm not sure there's a way around this issue. Have you ever heard that programming is about people? Of course you have, and you obviously believe it. But, does the business know that? Even if they've heard it, do they believe it?

I doubt your business does. Frankly, I doubt most of your colleagues in the industry do. I still know far too many programmers who think that their only responsibility is to write code that creates features. If that were true, if we were nothing more than line workers delivering feature after feature, it would be plausible that productivity shouldn't suffer no matter where the factory exists.

But, it's not true. Being a software developer is about communication, collaboration, analysis and coding, at least. Being a phone call away instead of a face to face conversation away impacts communication and collaboration. Thus, productivity is impacted. There's no getting away from that.

How can you convince your business of that? I haven't solved that problem yet, unfortunately.

What could be
I do think Fred had the right ideas. He described scenarios that had previously benefited from distributed development, and what made those situations succeed.

The first suggestion is to get everyone together. You want the team to gel as one entity. Do version one entirely on-site if possible. However, don't do it with all local resources. Bring people from the desired off-site location to work on-site for the first release. The team members will build trust and friendships that last up to 6 months.

Once you are on version two you can move the desired team members back off-site. However, the travel isn't over for anyone. The off-site team should always have at least one member from the on-site team with them, likewise the on-site team should always have at least one member of the off-site team present. These aren't week long trips either. Each member of the team should visit the other location for a month, once every five to six months. That level of in-person communication should lead to high levels of trust and understanding.

The travel situation is even more drastic for the analysts and stakeholders. They should split their time between the two teams, if possible. Neither team should feel like the A team or the more important team. Any implication that one team is above the other team will lead to negative productivity impacts.

That might sound drastic, but it's the price of doing off-site development. The cost doesn't stop there.

Both team locations are going to need to invest heavily in infrastructure. The best video conferencing software and highly reliable bandwidth will also need to be purchased. The idea is to foster communication in every way possible. Without communication and collaboration, the project is doomed.

Open Source
Before anyone points out that it's hard to argue with the success of Open Source, I'd like to be clear -- I'm not. Open Source is obviously successful and developed most often in a distributed manner. However, there are a few differences that, I believe, make it a different situation entirely.

First of all, most people aren't paid to work on Open Source. When someone isn't paying you, you can often do whatever you feel like, whenever you feel like it. If someone is working in the same area of the code as you need to, you can just put off your changes until they are done.

However, the reality is that most people aren't usually working in common areas when they work on open source. Most open source projects are maintained by a few people who work within specific portions of the codebase. If changes need to happen in "your" portion of the codebase, you often queue them up to work on after you finish your current task.

Since there's little conflict between what you work on and what other team members work on there's significantly less communication and collaboration required, and what is necessary can happen at a much slower pace. If you need to make a change, it doesn't often need to happen right away. It can be put off until the team member on the other side of the world wakes up.

The codebase also evolves at a much slower pace. Six to ten people working in the same codebase 8 hours a day move much faster than the average Open Source project that sees 3 developers working a few hours a day.

Distributed development does work for Open Source, but that's not what I'm talking about.

Conclusion
I have heard of companies successfully doing remote pair programming and distributed development. One recipe I've heard is that everyone is off-site in different locations. I can see how that would work since it requires everyone to adopt a new work routine and make the best of it. While I believe it's possible to be successful, I think it's still bleeding edge at this point. You probably don't want to "try this at home" quite yet.

I think Distributed Development is probably the way of the future. As bandwidth and experience is more available the industry will continue to evolve in that direction. However, I think it's still probably about 5-10 years from being mainstream.

Pair Programming all the time

I was having a discussion with a friend a few days ago about Pair Programming. I am, obviously, an advocate, but my friend doesn't believe in it.

Many people do not believe in Pair Programming (pairing). Most of those people don't agree with the benefits of pairing. However, my friend does believe that pairing is beneficial, he just does not believe in pairing all the time.

This is where semantics become very important. He was defining all the time as every minute that you are at work. I define all the time (in terms of pairing) as when I'm writing code that I'm going to commit.

There's plenty of time in the day that I spend on my own. Here's a few examples, but it's not representative of everything I do solo.

• Read about a library that might help us later on.
• Spike a new way to solve a complex problem.
• Debug a tricky issue.

Each of the above tasks I often take on without a pair. Usually I end up asking for help while I'm working alone, or I ask for someone to review my conclusions, but I don't force myself to pair when I'm not sure what direction I'm headed in.

Patrick Kua talks about working in two different modes, Experimental and Focused, in the context of Test Driven Development. I agree with Patrick and I believe the discussion also directly applies to Pair Programming. When you know what you want to get done, pairing ensures that you do it well. But, when you don't know what you need to do, it's generally a pain to try to talk through the problem with your pair. Talking through a problem can be helpful, but I often like to get a decent understanding before trying to explain it to someone else. I also like to be able to stop going in one direction and immediately switch to another if I spot something interesting.

Pair programming is a good thing, but like all good things, it's best when done in moderation. There are times when you do not need to pair, and Wikipedia has a decent list of reasons that people are opposed to pair programming. But, those things should not discourage you from giving Pair Programming a fair shot.

Given the right set up and approach, I believe pairing is the most efficient way to deliver quality software.

Pair Programming thoughts

It's very rare that I go to a client and pair programming is not an issue. Developers love their desks, personal keyboard configurations, and music. I like that stuff too; unfortunately, any personal space benefits or keyboard configurations cannot make you more productive than a team of effectively pairing developers of the same skill level. I can't prove that, but you can't prove that I'm wrong either. Of course, to begin (a futile) attempt to prove which is more effective we would need to decide on what we were measuring. Building software isn't only about the number of features delivered, it's also about the quality of the software delivered. It's also about having a team that can maintain an application as (inevitable) turn over occurs.

That's what's so great about Pair Programming, it improves the quality of software while spreading knowledge and best practices at the same time. Everyone benefits from the sharing of knowledge from small things such as efficiency gaining key short cuts to large things such as understanding the big picture of the project and spreading common patterns throughout the system.

Adopting pair programming isn't as hard as you might think. In May of 2005 I wrote that setup is important. I was wrong, setup is not important, it's the most important step towards adoption. Anyone looking to bring pair programming into their organization doesn't need to do much. Get tables large enough for several team members to sit in the same area comfortably. Get the latest and greatest desktops for the pairing area. (My current client got me a beautiful Mac Pro). Get a desktop with dual video out if possible, or get a video splitter. Buy 2 keyboards, 2 mice, and 2 (large) monitors for each pairing station. If the pairing stations are the best systems to work on, developers will naturally migrate to those machines.

70% of ensuring adoption success is work station set up.

I suggest not mandating pairing, let it happen naturally. I also suggest allowing the developers to keep their desks. Everyone needs an area to escape to and read slashdot when they need a break. If you just bought everyone 30 inch monitors you may need to move those to the pairing stations and give everyone small monitors for their personal desks. The idea is to allow people to have their space, but encourage them to use the pairing stations by providing a superior set up.

20% of ensuring adoption is ping pong pair programming.

Ping pong pair programming is fantastic at keeping everyone involved and given the opportunity to drive.

The remaining 10% will vary by organization, but if you handle the first 90% the rest should just fall into place.

When not to pair

Last night, while talking with Mike Roberts and Martin Fowler the topic of Pair Programming came up. We are all proponents of Pair Programming, but inevitably the question came up concerning when Pair Programming isn't recommended. I've always liked the suggestion that any activity that requires an artist can be done more accurately/effectively while pairing.

It's not uncommon to hear that developing software is an art. This is a general statement that is often true, but it's the tasks that don't require an artist that I believe can be done without pairing. What tasks don't require an artist? I would say any task that has only one right answer. For example, the task "Table Users needs an index on the Login column" likely only has one correct implementation. Adding an index can be done a few different ways, but I expect a project has a convention on altering tables and adding the index in that way is the correct execution of the task.

I do believe tasks that have only one correct answer can be done without a pair, the tricky bit is finding tasks that have only one correct answer.

Uninterested Pair

Sometimes your pair is uninterested in the task at hand. It's never fun for either person when working with an Uninterested Pair.

There are several reasons that a pair can be uninterested, but that isn't going to be the focus of this entry. Addressing why a pair is uninterested is a people question that I'm not interested in addressing in a general way.

A benefit of pair programming is getting the best solution when two developers collaborate. Clearly, an uninterested developer is not collaborating, thus the solution is likely inferior. At a minimum, the solution is as good as it would have been and 1 person's time was completely wasted.

The problem with uninterested pairs is that they can spend an entire day paying little attention and contributing almost nothing. If you find yourself stuck with an uninterested pair there are a few things that can help. Dealing with an uninterested pair is very similar to dealing with a Distracted Pair. Ping Pong Pair programming helps turn an uninterested pair into a contributing pair; however, often their level of contribution isn't up to their full potential. I've found that when dealing with an uninterested pair it's actually more beneficial to feign confusion.

Feigning confusion can be boring, really boring. You generally have a grasp on what needs to be done. You also generally have the solution in your head. You can implement this solution on your own and bring the uninterested pair along for the ride; unfortunately, in my experience that's exactly what happens. But, simply taking the uninterested pair along for the ride isn't the best long term solution. That pair may someday be asked to improve the existing solution. If they can't, because they weren't paying attention, you may be taken away from your task. Worse, you may be off the team and the context of the code is permanently lost.

So, feigning confusion is boring, but it is also in the best interest of the team. Instead of implementing the solution, ask your pair: How we are going to get this done? Don't accept their first answer. Their first answer is likely going to be fast, but incredibly ugly. Provide your own input, but don't let on that you have a solution. Instead, stick to asking questions. Chances are, you are going to understand their solution. It doesn't matter if you understand their solution, pretend that you don't. Force the uninterested pair to write the first 3 tests and implement the code that causes the tests to pass. At that point, take over and write a test, but force them to implement the solution. Then slowly proceed into Ping Pong Pair programming, but don't jump straight into it. Instead, force the uninterested pair to do about 65% of the coding. It shouldn't take long for the uninterested pair to be a fully contributing pair, which benefits everyone.

Distracted Pair

Ever since I wrote Spellchecking Pair I've been noticing other patterns concerning pairing. Distracted Pair, as the name implies, is a pair who is easily distracted by their surroundings.

Distracted pairs tend to spend less time typing, because they are always busy helping everyone around them. Distracted pairs are not useless; in fact they generally contribute significantly to the code the pair is working on. However, distracted pairs are rarely contributing at their full potential because they are generally attempting to solve the problems of multiple pairs at the same time. Some distracted pairs can also spend too much time checking email and doing other ancillary tasks.

Joel believes that open space working areas are fun but not productive. While I don't agree with him, I can see how a few distracted pairs could easily make a manager draw that conclusion.

I've been a distracted pair. I've also worked with several distracted pairs. I believe that it happens to all of us from time to time. In the past I've seen distracted pairs managed by creating rules. For example, a "no personal laptops in the development room" rule existed on a previous project. This rule can help address the problem, but it creates other problems.

My preferred method of handling a distracted pair is to practice Ping Pong Pairing. Ping Pong Pairing forces both pairs to be paying attention at level one. Another nice attribute of this suggestion is that it doesn't require any additional rules that could have problematic side effects.

I'm led to believe that Joel doesn't believe in Pair Programming either, so my solution may be worthless to him. However, if you are working in an environment where Pair Programming is embraced, I suggest using Ping Pong Pairing to get the most out of working with a Distracted Pair.

Spellchecking Pair

Pair programming is a controversial topic. The majority of the projects I've been involved with always have at least one skeptic on the team. The skeptics always cause me to take another look at the practice and see if the specific project provides a new point of view to the discussion.

On my last project I learned that large gaps in talent can turn a teammate into nothing more than a spellchecker. This generally seemed to happen when one member of a pair was significantly more skilled than the other. In the case of an experience gap the more skilled pair can slow down and mentor the junior pair member; however, sometimes a story needs to be completed as soon as possible. In the cases where time is very valuable it seems to make sense to rotate in a more experienced teammate or to split the pair until a more experienced teammate can join the pair.

While I generally prefer pairing, if a teammate is providing nothing more than spelling suggestions it is probably not the best use of his time. Furthermore, when an experienced teammate is required to slow down to explain things, then the pair is not closing the card as quickly as possible.

Pair Programming Anti-Patterns

Pair programming is hard. Previous to working at ThoughtWorks I had a manager who requested that the team do pair programming. The idea failed miserably, but it wasn't pair programming that was flawed, it was our approach. Below is a short list of the mistakes I've witnessed, but it's by no means a complete list.

• People who don't care. This is the biggest pair programming killer. If your employees are only there for the paycheck they will make pair programming fail. Getting two employees on the same schedule is hard. Once two employees get on the same schedule one will daydream while the other works. This is very boring, but to people who don't care, it's better than working.
• Strong code ownership. It's often very hard to motivate people to care about code they aren't responsible for. For more info on code ownership see Martin's bliki entry.
• Inconsistent workstation setup. People like to work in their own environment. Unfortunately, when pairing you are unlikely to find two people who agree on what an environment should be. The solution is to provide pairing stations with standard setups. Instead of trying to learn multiple environments, the team can work on one shared setup.
• Small work area. People like to be comfortable. Putting two chairs in one cube where one person's view is obstructed is very unlikely to produce good results. On the ThoughtWorks projects I've been staffed on we always have a project room that has enough room to sit side by side, two monitors that mirror the desktop, two mice, and two keyboards. This allows either person to take control when necessary.
  

When 1 + 1 != 2

The common belief about pair programming is that you achieve the productivity of 1.5 developers on their own. The problem with this measurement is that the productivity of each developer is unique to that developer. Also, it assumes that the developer is productive at a steady pace for 8 hours a day 5 days a week.

I believe that in rather common situations pair programming can be much more or less productive. And, while 1.5 may be the mean, it's more often much more or less.

Since I joined ThoughtWorks I've noticed increases in my productivity. This is for several reasons, including:

1. Pairing doesn't allow slack time. In the past I often completed tasks ahead of schedule and ended up with extra time. Usually, I filled this time with browsing, emailing, etc. However, pairing forces me to focus and move on to the next task.
2. Pairing gives you 2 points of view. The continuous code review provides confidence. There is no better feeling than programming with confidence. Test driven development gives you some confidence; however, it only validates what you test. Pair programming goes above and validates the design from 2 points of view while development is being done. Additionally, 2 points of view limits wasted time. Have you ever had the feeling that what you were doing was wrong and you were going to have to throw away the code? Unfortunately, when I'm not pairing I usually finish, and then look at what I can improve. Then, often, I have to explain the code to someone else to get their point of view. And, in the end I throw most of the code away. However, when I pair, the other developer is following my train of thought and we can stop, visualize the end result, and discuss better options.

Just these two examples make me significantly more productive. However, in the past I've been very unsuccessful with pair programming. I can very vividly remember what went wrong.

1. Workstation set up. Have you ever tried to drive on someone else's computer when they used a natural keyboard and you are used to a laptop keyboard? You adapt, but it's annoying. Obviously, productivity will suffer some.
2. Motivation. My first pairing partner and I had something in common, lack of motivation. We couldn't get our schedules to match, and we ended up spending much of our time explaining what we had done while the other person was away. Then, when we did pair, we weren't focused and spent much of the time day dreaming. Why pay attention, someone else was doing the work. We were both slackers, but pairing couldn't remedy our slacking if we weren't motivated.
3. Speak the language. Nothing is more frustrating than looking to someone for design advice and they are stuck on something syntax related.

Issue 1 is minor, but combine it with 2 or 3 and productivity becomes horribly low. Even 2 or 3 alone can destroy the flow of development.

Do you know anyone indifferent about pairing? I don't, it's a love or hate relationship. I think this is largely because of the productivity that is achieved. If you have a successful experience you see how great it is and love it. Obviously, it can also be painful and very unproductive, thus the hate emotion. But, if you don't love pairing, I'd have to ask if you actually love programming.