On Pair Programming: Excuses - Part 2

Last Saturday I attended Minnebar, a local (un)conference here in the Twin Cities that attracts somewhere towards 1000 of the area’s best tech, design, and entrepreneurial talent. In the last session of the day, there was some side talk about team best practices and one mentioned was pair programming. At the end of the session, someone asked “How do I convince my manager that pair programming is worth it? He says he doesn’t want to pay two people to do one person’s work”. Yes, that is a real excuse. I’ve heard it before myself. Few of the answers offered were very serious or if they were, they were not practical. Normally I cannot simply fire my manager and get a new one. Instead, with a little education, some coaching, and challenging the leadership/management team to take a risk, you can see where pair programming will take you, your team, and your product. And maybe, just maybe, it won’t work out. It’s not for everyone nor every project, but without giving it a shot, you will never learn if it will work or not.

While Part 1 focused on programmer excuses, this will focus on excuses made outside of the programmer role, from the business perspective.

So let’s review.

What is Pair Programming?

Pair programming is a software development practice where two programmers sit at the same computer and solve the same problem together, as a team. Remember that this problem the team is solving, whether it be a bug, new feature, or configuring a server, is a team problem. In the most effective form of pair programming, each member of the pair is doing something different and complimentary to the other person. One is thinking at a code or unit level and is doing the typing. The other is thinking more abstractly and strategically, both for the problem at hand and how it fits into the system and product as a whole. These roles will switch frequently, and with a well-matched pair, it happens naturally.

Pair programming is akin to having a co-pilot while flying. Each member of the pair acts as the other’s conscience and challenges the other to think more about why and how to solve a problem. They are forced to explain what they are doing and why, all at the same time they are doing it. It takes practice. As the pair encounters problems, they brainstorm ways to solve them together. They decide together to spend an extra hour refactoring something.

So what are the excuses?

It’s Too Hard to Start Mid-Project

Let’s face it. Delivering software is hard. Many projects run late or over budget right from the start. It can be terrifying to start a new practice mid-project when it has the potential to disrupt the timeline or budget. Potential. But what if by practicing pair programming, you reveal a new challenge you hadn’t anticipated? A critical architectural flaw. An inaccurate business assumption or requirement. Would you rather know that challenge mid-project so you can proactively manage it or would you rather learn about it from your users after the project has launched?

Only Half As Much Work Will Get Done

There is this assumption that removing a computer from two people will reduce the amount of typing that happens. We are not typists. Believe it or not, the majority of our work is not dedicated to banging away at the computer. Our work takes thought, brainstorming, and collaboration. And by definition, collaboration requires… talking and working together.

We can also use the doctor/server metaphor here. Pairing is going to help you move into more of a doctor role, where you are asking more questions about why you are solving a problem a certain way or if you are even solving the right problem. Sometimes the right thing to build may not be written down in the acceptance criteria of the story. Building the right thing might actually involve talking about it.

But let’s be honest. There is typically a short term productivity loss, but costs do not double with pair programming. Some research here and here has reported that only about 15% more time is spent. However, this cost is recovered with increase in quality, spread of knowledge, and increased truck number. I’m not going to go over the math here, but those references lay it out pretty nicely for you.

Why Would I Hire Two People To Do the Work Of One

First of all, why is this project one person’s job? Isn’t the success of the project based on what the team accomplishes as a whole?

Second, see the section above.

Nobody Is Working. It’s a Social Hour Around Here!

Are you sure it’s a social hour? Listen carefully. Is the pair discussing which map implementation would best fit this problem or are they really talking about the latest gossip? Pair programming is actually going to create less disruptions. When a pair is deep in a discussion about a problem, there are less likely to be drive-bys because people don’t want to interrupt. The pair is focused. People are also less likely to succumb to distractions such as emails, meetings, surfing the web, facebooking, and tweeting because there is an element of peer pressure.

As for talking about the latest gossip, keep in mind that this is a way of pair bonding. As a pair gets to know one another, they begin to trust each other. And if they trust each other, they are going to start taking the kind of risks that you want them to take. The kind that will elevate your team, product, and company to new levels.

What are your thoughts?

As I continue to practice pair programming and have conversations with friends and colleagues about this topic, my opinions are ever-evolving. So keep in mind this is a work in progress and your opinions and experiences are very welcome in the comments.