Pair programming has a lot of known benefits, but is it always the easiest way to get work done? Is your team on the verge of adopting pair programming? In this post, I want to talk about my experience with pair programming and suggest an activity that will help improve the benefits and reduce the risks when applying this technique.
The Benefits:
- Improves Focus: People usually talk about code quality, but for me it’s more than just code. The focus of a pair also affects the relationship with stakeholders, be it in face-to-face meetings or via email. When writing an email, the message can be reviewed to avoid mistakes. When in meetings, it’s easier to fill gaps in the updates and have constructive discussions on the outcome of the meeting afterwards. In most cases, a pair tends to communicate better than just one person
- Fewer defects: Every time I’ve had to work alone on code that I’m not familiar with, I’ve had to work a lot harder on code reviews to make sure I don’t forget anything. Despite this, there are times when I get things wrong or find them to be more complex than they actually are. When I'm pairing, I can say for sure that the work has a lot less defects and is usually simpler. There’s always someone to watch out for errors and over-engineering
- Business Continuity: Business continuity is very important in any project, and pair programming is a key practice to achieve it. There is a constant stream of context sharing, and this ensures that the task can be worked on even when a key person goes on leave
These are a few positive outcomes of pair programming, but it’s not always a rosy picture. Pair programming does require a team with some degree of maturity, and people need to feel comfortable working with one another.
The Challenges:
- Infrastructure: The most obvious issue in pair programming is the team setup. From things such as editors/IDEs to keyboard layouts and OS, if your team doesn’t have a common setup for everyone, it's going to be really hard to get people comfortable with pair programming. Having dedicated workstations can be of a great help, but also agreeing on a common setup or having a way to share the code in a way that anyone can use their own configuration, work just as well
- Fatigue: I have heard so many people say that they were exhausted after a day or a session of pair programming. The increased focus doesn’t come easily, it takes a lot of energy to focus on the problem, share your thoughts and hear the other person. It also takes a lot of effort to zone out and not check your twitter feed, while someone by your side is depending on you
- Ego: Be it when you are pairing or even when you are considering pairing with someone else, it's important to stay humble and hear the other person. I have seen so many instances when people argue, rather than discuss. I find this to be a big issue in pair programming. After a few situations like this, pairing just becomes so painful that no one wants to do it, and will even advocate against it!
Everything is relative:
All the points that I have made here are based on my experience. They are all debatable and context dependent. Each advantage has its own cost and requirements, so they can’t be taken for granted. The best thing you can do is to talk to the team and let them choose how they want to work.
There could be situations where pairing is not really flowing and people are not comfortable with it. Pair rotation isn’t happening naturally or maybe the team is unsure if they should consider pairing at all. In situations like these, I suggest an activity that may help you figure out what works best within your team.
That Person and This Person:
This is originally a retrospective activity posted by Paulo Caroli and Tainã Caetano (http://www.funretrospectives.com/that-guy-this-guy/), but I have applied it on specific conversations about pairing and the result was really good.
You start by dividing a wall in two sections, "Don't be That Person" and "This Person rocks!":
In the first section, people write an example of behavior they didn't like. It doesn't have to be with the current team, it can be any example that they have encountered. Try to have everyone put up at least one example on the wall.
The second section should have examples of what people really liked. Again, it can be any example and everyone should put at least one example.
After that, go over the wall and let the team talk about each example. What you want to have at the end of the session is not a list of what the team should or shouldn’t do, but rather a list of best practices. That's why you need to make sure that everyone in the team talks about at least one of their examples.
The conversation should be about how the team feels regarding certain types of behavior, do people agree that this is a good thing to do? In some cases the behaviour could be apparent, in others it may merit a deeper discussion.. Avoid conversations about something being right or wrong, or very context specific discussions. This is because you need to find things that the team likes, not rules people should follow.
Seek feedback constantly:
I see this activity as a good way to boost the team morale, having this conversation usually leads to people being more open to each other, thus leading to more conversations. A good way to sense the dynamics of a team is by observing how much they talk to each other. A quiet team usually means that people are disconnected and a low amount of information is shared.
If your team is trying to adopt pair programming, schedule one-to-one conversations with people to get a better sense of how they enjoy working in pairs. Talk to the leadership to see if they are feeling the benefits of it, specially if they had to be convinced about it. Metrics like the quantity of defects found are not really fair, but can be an option, just make sure they are not the drivers of the decision.