... about fear of pair programming

Although pair programming has been around since 1999, I only heard about it 5 to 10 years later. Software quality was high on my list of values, but finishing a task within the estimated time was a lot higher. And because all our estimates were wrong (too low), I was too engaged in meeting the deadline. I was in a constant state of haste that transformed into a state of panic when the sprint drew near its end. 

Back then, I thought pair programming was wonderful but a bit of a waste of time because you'd put two developers on a task that could be done by one. I knew the arguments about the lower bug rate and better design when doing pair programming, but I didn't really believe they were sufficient to compensate for the wasted time. Finally, I was pretty sure I could not sell the idea to my project manager.

ffwd 10y

That was almost 10 years ago. I think differently now. Meeting initial estimates is not that important to me anymore. It's not at the top of my list anymore. Reducing software complexity is. Understanding the business domain too.

For me, pair programming has lots of advantages. It's an effective tool to get new team members up to speed. It's a way to avoid wasting too much time in dead end streets. It's a great way to learn from others. But most importantly: it's the best way to have a shared understanding of what the domain is, what the solution should look like and how it should be solved.

Out of fashion

I found that selling the idea of occasional or regular pair programming to project managers is a non-issue. I've yet to meet a manager who's against the idea of pair programming. They seem to understand the added advantages and trust their team to not needlessly waste time.

The problem is not with the management. 

It's with - some/most of - my team members. They don't really want to. Not all will admit it, but I can feel enthusiasm sink fast whenever I suggest to pair program in order to solve a certain task. It's like pair programming has gotten out-of-fashion (some argue that it never got into fashion in the first place). Perhaps it's a personal thing and they just don't want to pair with me. I don't know. 

When asking my colleagues I get reactions similar to the following: 

I don't like pair programming because it's too intense. I want to take time to understand the problem and look for solutions.  

I'm afraid we'll waste too much time and that won't look good on our next stand-up meeting.

I want to drive in dead-end streets, return on my steps and try different routes. I want to be able to make mistakes and bang my head against a wall.

I think it might make me look stupid when I don't understand what my co-programmer wants me to do.

I understand all of this. When you're new to a project, things might look overwhelming at first. Pair programming makes you vulnerable. You have to leave that safe shell, called your desk, and directly expose your thoughts and ideas to your partner. This can only happen when there's enough trust within the team and when every team member is willing to learn from others.

Together everyone achieves more?

Development is all about team work. It's scrum teams, agile teams, team retrospectives, daily team stand-ups. It's team everywhere. Everyone's a team player, playing that team song. Everything is put in place to make that team work as efficient and effective as possible. 

However, the moment that daily team moment is over, we all go back and work in our own little individual world, developing our own little code in our own particular style having our own thoughts about what clean code should be. We think of all sorts of solutions and abstractions, protocols and schemes, but we neglect to communicate them to the rest of the team. Banging our head against the wall at every misunderstanding of other developer's intent. 

That's not a team. That's only a group.

Conway in the small 

For me, pair programming is the best way to keep your software project coherent. To keep it in a consistent state. To mix my ideas and style of programming with that of my team members. 

There's different ways of doing pair programming. Driver-conductor, tutor-pupil, mob programming, ... I don't really care about that. Any form will do for me.

When pair programming does not occur, the program inevitably breaks down in an aggregate of styles. Of pieces that I wrote and pieces that my colleague wrote but didn't reach any synergy. Of abstractions that my team member found useful but are not used any further because I have other abstractions in mind that conflict with hers. It's Conway's law in the small. When not pair programming, every team member creates her own little program and coherence is lost.

After 10 years, I don't have that sense of emergency anymore at the end of a sprint when I realize that my estimates were overoptimistic. Nowadays, I get that feeling of discomfort, when I realize that the intent of some piece of code was misunderstood by other team members. That the project is going in all directions at the same time. That complexity is needlessly added in the name of standardization or "because that's how we did it in another project". 

I just hope I will be able to convince my colleagues about the value of pair programming and how much value it adds to any project. Perhaps we do need more trust first.

Greetings
Jan