Pair programming is a great way to share knowledge. But every developer is different, does pairing work for everyone?
Pairing helps a team normalise its knowledge – what one person knows, everyone else learns through pairing: keyboard shortcuts, techniques, practices, third party libraries as well as the details of the source code you’re working in. This pushes up the average level of the team and stops knowledge becoming siloed.
Pairing also helps with discipline: it’s a lot harder to argue that you don’t need a unit test when there’s someone sitting next to you, literally acting as your conscience. It’s also a lot harder to just do the quick and dirty hack to get on to the next task, when the person sitting next to you has taken control of the keyboard to stop you committing war crimes against the source code.
The biggest problem most teams face is basically one of communication: coordinating, in detail, the activities of a team of developers is difficult. Ideally, every developer would know everything that is going on across the team – but this clearly isn’t practical. Instead, we have to draw boundaries to make it easier to reason about the system as a whole, without knowing the whole system to the same level of detail. I’ll create an API, some boundary layer, and we each work to our own side of it. I’ll create the service, you sort out the user interface. I’ll sort out the network protocol, you sort out the application layer. You have to introduce an architectural boundary to simplify the communication and coordination. Your architecture immediately reflects the relationships of the developers building it.
Whereas on teams that pair, these boundaries can be softer. They still happen, but the boundary becomes softer because as pairs rotate you see both sides of any boundary so it doesn’t become a black box you don’t know about and can’t change. One day I’m writing the user interface code, the next I’m writing the service layer that feeds it. This is how you spot inconsistencies and opportunities to fix the architecture and take advantage of implementation details on both sides. Otherwise this communication is hard. Continuous pair rotation means you can get close to the ideal that each developer knows, broadly, what is happening everywhere.
However, let’s be honest: pairing isn’t for everyone. I’ve worked with some people who were great at pairing, who were a pleasure to work with. People who had no problem explaining their thought process and no ego to get bruised when you point out the fatal flaw in their idea. People who spot when you’ve lost the train of thought and pick up where you drifted off from.
A good pairing session becomes very social. A team that is pairing can sound very noisy. It can be one of the hardest things to get used to when you start pairing: I seem to spend my entire day arguing and talking. When are we gonna get on and write some damned code? But that just highlights how little of the job is actually typing in source code. Most of the day is figuring out which change to make and where. A single line of code can take hours of arguing to get right and in the right place.
But programming tends to attract people who are less sociable than others – and let’s face it, we’re a pretty anti-social bunch: I spend my entire day negotiating with a machine that works in 1s and 0s. Not for me the subtle nuances of human communication, it either compiles or it doesn’t. I don’t have to negotiate or try and out politick the compiler. I don’t have to deal with the compiler having “one of those days” (well, I say that, sometimes I swear…). I don’t have to take the compiler to one side and offer comforting words because its cat died. I don’t have to worry about hurting the compiler’s feelings because I made the same mistake for the hundredth time: “yes of course I’m listening to you, no I’m not just ignoring you. Of course I value your opinions, dear. But seriously, this is definitely an IList of TFoo!”
So it’s no surprise that among the great variety of programmers you meet, some are extrovert characters who relish the social, human side of working in a team of people, building software. As well as the introvert characters who relish the quiet, private, intellectual challenge of crafting an elegant solution to a fiendish problem.
And so to pairing: any team will end up with a mixture of characters. The extroverts will tend to enjoy pairing, while the introverts will tend to find it harder and seek to avoid it. This isn’t necessarily a question of education or persuasion, the benefits are relatively intangible and more introverted developers may find the whole process less enjoyable than working solo. It sounds trite: but happy developers are productive developers. There’s no point doing anything that makes some of your peers unhappy. All teams need to agree rules. For example, some people like eating really smelly food in an open plan office. Good teams tend to agree rules about this kind of behaviour; everyone agrees that small sacrifices for an individual make a big difference for team harmony.
However, how do you resolve a difference of opinion with pairing? As a team decision, pairing is a bit all or nothing. Either we agree to pair on everything, so there’s no code ownership, regular rotation and we learn from each other. Or we don’t, and we each become responsible for our own dominion. We can’t agree that those that want to pair will go into the pairing room so as not to upset everyone else.
One option is to simply require that everyone on your team has to love pairing. I don’t know about you: hiring good people is hard. The last thing I want to do is start excluding people who could otherwise be productive. Isn’t it better to at least have somebody doing something, even if they’re not pairing?
Another option is to force developers to pair, even if they find it difficult or uncomfortable. But is that really going to be productive? Building resentment and unhappiness is not going to create a high performance team. Of course, the other extreme is just as likely to cause upset: if you stop all pairing, then those that want to will feel resentful and unhappy.
And what about the middle ground? Can you have a team where some people pair while others work on their own? It seems inevitable that Conway’s law will come into play: the structure of the software will reflect the structure of the team. It’s very difficult for there to be overlap between developers working on their own and developers that are pairing. For exactly the same reason it’s difficult for a group of individual developers to overlap on the same area of code at the same time: you’ll necessarily introduce some architectural boundary to ease coordination.
This means you still end up with a collection of silos, some owned by individual developers, some owned by a group of developers. Does this give you the best compromise? Or the worst of both worlds?
What’s your experience? What have you tried? What worked, what didn’t?
Actively Lazy 
Great post! My team has struggled trying to find out pairing identity since we formed last year. I definitely see introversion as a factor, but the education system as a larger one (http://proseand.co.nz/2014/06/16/fear-of-plagiarism-is-killing-collaboration/).
Fortunately since I wrote that blog post, I think our team has begun to find where pairing works for us. First, I should mention that we have three developers, so pairing is naturally awkward. Pairing full-time isn’t possible due to the odd number, and we don’t all work at the same hours despite being co-located (I’m usually in two hours earlier).
Rather than making anything formal about how we would pair, what we’ve done is try to keep the minimum number of stories in progress at any time. Hence if there is a story going on, do all that you can to help it to completion rather than pulling a new one off the board. This has resulted in lots of pairing and collaboration. Because we’ve not made any official rules, it’s also possible for us to divide the story into tasks at each of our work stations and work alone as necessary. I find this helps me tremendously because as you noted pairing can be very exhausting for introverts like me.
As much as I prefer working alone, I know from experience that our work is much more successful when pairing. I would say that pairing isn’t for me per your post. However, my desire to be part of a productive team building successful projects outweighs my inclination for individualism.
Interesting post! Never thought of it from that angle before.
That sounds like a good approach – on small teams it is hard (why is it always three developers?!), but you can still make it work but it seems to need constant attention and effort to maintain it.
I think the hardest part is acknowledging that we work better when pairing. There’s a bit of an ego problem to get over, to admit that you do better work when not left on your own.
The ironic part about the pride portion, is we forget that pairing allows us to share the practices, philosophies, etc that we hold so dear. 🙂 Both developers on my team are considerably less experienced than I am, and that doesn’t stop me from learning from them or getting better by having their input.
Hopefully through our retrospectives and our generally open communication as a team, we’ll be able to maintain an approach that works for us.
One of my clients wanted to improve quality. He decided that he would give pair programming a try. The developers did not like it. He started with mandatory pairing once a week. It did not work.
I came in to help. I ran a Coding Dojo where people where pairing, but it was more a funny/game environment than real work. In the retrospective several developers mentioned that the their pair had some interesting ideas they did not have. This was the first step to get them on board, to see/witness the benefits. Then I started pairing with them from time to time, to show what a real pairing session would look like. Now after a few months they are pairing more often and lost the negative attitude towards it.
The pairing is informal, if people fill like needing a pair, they ask for someone to pair with them, or if someone has no urgent task, he or she is walking around and offering to pair.
The desks are not optimal because there is not much space for the second/navigator. I also urged them to get a second keyboard/mouse for every workstation, so ppl would not have to connect keyboards up front. Even small things block the adoption. If it is not easy/nice to do, ppl will not do it.
To conclude I would say that in order to help adoption, imho you need
1) comfortable working conditions/equipment
2) make sure all developers see/know/felt the positive sides, e.g. get some experience in playground
2) spend some time training it
3) gradually increase percentage of pairing work.
Hope that helps
Thanks, Peter – you’re right, you absolutely can’t force things. I think we have a pretty relaxed attitude to pairing. For various reasons not all of us can pair every day, so there’s certainly a mixture of people working alone / pairing most days.
However – this post was more the observation that some people find pairing uncomfortable. Not necessarily that they don’t see it’s benefits, more that they actually don’t like doing it.
Sometimes its not a case of showing what successful pairing looks like: they’ve seen it and still don’t like it. Very experienced developers, in particular, can get a bit set in their ways!
Code knowledge can be shared even without systematic pair programming. I don’t usually do “real” pair programming, where people switch who owns the keyboard every so often and code the complete solution as a pair. But I do a lot of pair conception (we both look at the existing code, discuss what has to be done, then one developper actually implements the solution while the other goes back to some other work, still making himself available if some undiscussed problems arise during coding). That approach could be seen as the setting of boundaries as described in your article, but the boundaries are very fine-grained (I won’t look at how you implement that method, but we’ve discussed together what it should do and where you should put it, and even how it should be named).
And code review can ensure that another person gets in the loop too, even if it is after the fact. I’ve found that some developpers prefer code review to pair programming, even when the review results in “rejected” code that has to be worked on again.
Nice approach – I’ve seen this kind of “design authority” approach work well, ensures that the code isn’t completely unknown to others and helps ensure (with more inexperienced developers) that the work is being tackled in roughly the right way.
You’re absolutely right: some developers definitely prefer after-the-fact code reviews to active-pairing (I think I used to be such a developer). But there is this third approach (which could work with code reviews or pairing) of ensuring that someone understands the design, if not the line-by-line code.
Thanks for this great post. I was really hoping you would come up with a solution to the mixed-preferences problem. 🙂
Myself I experienced a team that worked really well with pairing, but when one very skilled solitary programmer joined the team broke down discipline. The newcomer ended up being the best performer and the model for the rest of the team, but the team stopped sharing information as well as they had before.
At least that was my interpretation of the situation.
I hope that you or others will be able to share insights about how to make both the solitary and the pairing programmers work well as a team.
Yeah it seems there are no easy answers. Thanks for sharing your experience, though – sounds like it was still a (mostly) positive outcome for you.