You guessed it; the topic of this blog post is pair-programming, but not only! Instead of giving you the theoretical benefits of the pairing with some appealing assertions like “You’ll increase your productivity by x%!!!”, I’ll try to explain why in my team we decided to stop coding alone.

Hunting the ghost tasks

It occurred to us that we were often facing ghost tasks. What is a ghost task? That’s basically a task on which someone seems to work but in fact nobody does. For example Bob felt sick 3 days ago, or he has left for vacation without finishing his task. Or maybe Bob has so many meetings those days that he can’t find any time to work on… so the task lets the dust settle over itself inside the “In Progress” column of the JIRA Board.

Why is it a problem?

Because you have to wait for someone available to finish what’s Bob has started or even worse, someone will have to stop what he is doing to switch on this task. Remember: increasing the work in progress is evil!  And this person has to cross his fingers, hoping that Bob has pushed some work on his branch. Otherwise he will have to start it all over again. But even in this situation, all the things Bob has learnt and understood to solve the task remains in his own head. And this new developer has to pay the learning curve again.

From a project management standpoint, how can you be predictive if the elapse time of a task always depends on the availability of the developer who has started the work?

How pair-programming fixes that?

Since the work is done in pair, if Bob is no longer available, his duo is able to continue the work without paying any extra costs of context switch. And there is always someone working on the task; because having two persons of the same duo unavailable at the same time is very unlikely.

From a group of N individuals to a team of N developers

It’s not because people are working in the same team that they are working together… Yes this is a paradox. On day during a daily stand-up, I surprised myself by being so bored that once the meeting has finished, I realized that I missed the speech of some of my teammates. So I asked two of them if they could remember about what the others said. And the result was pretty bad…

But why? Why can’t we remember about what people just said in a less-than-15-minutes-meeting? So the next day, I listened very carefully about what people were saying. And I was really surprised! For some of them, I just didn’t understand at all what they were talking about although we were in the same team for more than a year. For the rest, it wasn’t better; I could understand but those were topics I didn’t fell concerned about… because I was not currently working on it.

Everything became crystal clear since that moment. I realized that in the team people became specialized in their comfort zone and were continuously taking tasks on the same subject. So instead of having a group of people working together, it was like we had N teams of one people working only on the same part of the application.

Why is it a problem?

It seems very obvious those days that having very specialized people is a problem. When Bob takes his vacation, nobody is able to work on his domain so we just wait for him to come back. If you like to work this way, well I’ll save you some time, stop the stand-up meetings and just send an email to your manager every morning since the others don’t care about what you do…

Furthermore we realized that we were only able to help each others only on pure computer science problems. For the business domain or the feature you are working on, you are alone.

And seriously we can’t call that a team!

How pair-programming fixes that?

Well it seems very obvious that if you work with someone on exactly the same topic, he will naturally feel concern about what you do and be able to help you (unless he is a really bad teammate!). But not only during the coding phase, you should also do pair-reviews; I’ll take a bit more about that in the next section.

Because code review should not be a judging court

“Your honor, I didn’t reuse that method because I…” How many times did you have the feeling that a code review looks like a court where you have to justify yourself?

How many times did you have to rework a large part of your task because someone said that you shouldn’t have done that this way or because you missed a huge constraint?

Well, so many times for me, you can’t imagine. And you can imagine that this is not very effective to refactor one week of work because the information you needed was in Bob’s head (but he didn’t know!).

Why is it a problem?

Losing time and being frustrated at work are always a problem.

How pair-programming fixes that?

If Bob was working with you at the very beginning of your task, he would have told you what he knows. But that’s not the only advantage. Since Bob has a different experience than yours, he can challenge your bad ideas. And with a little technical discussion, you can converge to an optimal solution before trying so many useless things. This way you are making choice faster and when the code review comes up, it looks like the work was more deeply thought.

Sometimes the reviewer is wrong and narrow-minded. That’s always easier to win a 2vs1 battle than a 1vs1, Bob will help you to explain why things have to done like you did.

There is also something you have to consider here: pair-code reviews. Sit with a reviewer and let’s start the code review. You’ll both save time because you can explain in live the code and he won’t have to figure out by himself why things are like that. It’s always better to have a direct conversation than posting comments in a tool. One time I saw two developers who were arguing in their code review tool although there was only 3 meters between them. The discussion took two weeks… when they finally decided to sit together; it took them a half day to find a solution. What a waste of time!

Sharing the knowledge

This is really important to share knowledge, if in your team only one person is able to work on a topic; you got a single point of failure! One solution could be writing docs (yeurk!) But documentation is really expensive, not accurate, difficult to maintain and never up to date. Wiki page is a bad idea. You write/read it and you forgot that it even existed one day. Even if you know that this page exists, sometimes you struggle very hard to find it back because you are using synonyms of terms actually used on it.

One efficient way to share knowledge is the code review. Because during the review, you have to understand what is the purpose of the feature that some others have done and the way they implemented it. And you always learn when you read code! Next time, when you’ll work on that feature, you’ll remember the key things you saw during the review. Code review is so efficient in term of knowledge sharing that today in my team, every developer does all the code reviews. It makes us more efficient and more integrated.

So…

When we moved to pair-programming we noticed that:

• We had access to a wider knowledge before starting the work. Since people previously worked on different part of the software, their knowledge are complementary.
• We were making choice faster. How many times did you try so many different solutions before choosing one? If you pair you’ll realize that your teammate will challenge your bad ideas and if you agree on a solution, this is very likely to be the best solution you can do.
• Less remarks during code reviews. Because the work really was deeply thought.
• We were sharing knowledge faster. By design several people are learning at the same time on the same topic.
• The developer was no longer a deadlock, if he is no longer available, the work doesn’t stop.
• We felt more efficient.

But I cannot let you leave without taking about the less-shiny aspect of pair-programming.

Pair-programming has a cost: this is more demanding; you need to be always focus when you are working with someone and at the end of the day you might feel exhausted. But the more you practice it, and the easier it becomes.

Even if they try hard, you’ll see that naturally people can sometimes “split” by taking alone some task. This requires a lot of self-discipline.

Everyone is not made for pair-programming, some peoples hate it, and this is one thing you absolutely can’t impose to a team. The team must be convinced about it and apply it naturally with enthusiasm. The truth is pairing is not a silver bullet, it really depends on the people you got in the team but when it works, it works really great.

At the time I’m writing this blog post, my team is working in a constant pairing mode since 8 months and is really happy about it. I may write another blog post on how we set up pair-programming using XP in my team soon.