Yeah, Yet Another Blog on Pairing and Pair Programming.
Q 1. What are the disadvantages of Pairing?
My experience with pairing has been good so far. I‘m not too sure if I can really point out disadvantages.
1. One thing that does bother me a little is, it can get into the way of your creative thought process sometimes. But most of the times, I‘m happy with the end results.
2. Some people also complain about the trashing of ideas that go on when people pair. It might feel like the pair is wasting a lot of time just abstracting arguing about the approach or their understanding of the problem at hand. Again, this is not really a disadvantage of pairing. Any time you have more than one person, there is going to be differences in their perception and approach. According to me, it better to clarify this sooner than later. Usually if the pair cannot converge on one approach, one of them drives [implements] her/his approach. If it works, they move on, else the other person drives her/his approach.
3. There might be other interpersonal issues that could arise while pairing. But its better to resolve them rather than ignoring them. And it‘s not unique to pairing. Any team activity would have the same issues. A good example that comes to my mind is ego clashes between people. It‘s better to resolve it rather than letting it grow.
Couple of things one should remember:
1. Pair programming is not about typing code. If you have watched a really good pair programming session, there is very little typing and more of communication/ discussion. Designing good systems is not about typing code, it needs a lot of brainstorming. No I‘m not suggesting big upfront brainstorming sessions. You need Just-In-Time brainstorming. Closer to the time of implementation. Also people often under-value the feedback they get from code. Everyday I learn from my code and from other people on my team.
2. Pairing is not just limited to programming. We do a lot of cross-functional pairing. Developer pairing with the Business Analyst to write automated acceptance tests. Developers pairing with QA to recreate bugs. QA pairing with BA to do exploratory testing and so forth.
Q 2. Some people do not want to pair program, they are lone contributors and pairing slows them down, they just stop thinking, they feel less productivity? How do you deal with this? Can we possibly reduce pair programming hours? May be ask people to work separately for 2 hours and sit for 30 minutes to pair program.
Like any skill/habit, people take time to learn it.
When I was in University, the natural thing to do for me was to work with others [Profs and students]. In my days I learned programming by working with other students [pairs]. Once I joined a software company, I drifted on my own and after a while I got used to working on your own. Changing this habit back to working with another person took some time [a week or two]. After that I don‘t see “the pair slowing me down“ thing happening much.
Every single time I‘ve worked with a team, “lower productivity” comes up as the first argument against pairing. There have been a lot of studies done, which prove that this is a myth. Let me back up a bit. How do you define lower productivity? Amount of work done in an hour or day or sprint/iteration? This looks like a real short-sightedness. We are talking about software project which have a bigger life span than hours or days or sprints/iterations. Shouldn‘t one consider, UAT bugs, production bugs, support calls, ramp up time for new team members, maintaining all kinds of crazy documents, etc also when they derive productivity numbers?
Faster learning, better communication, collective code ownership, shared understanding, evolutionary design, better estimates, continuous code review, etc all go hand in hand with Pair programming.
So I would strongly discourage people working separately for 2 hrs and pairing for 30 mins. I would reverse the time.
Lots of times on teams, people want time to check their emails, answer some calls, go to meetings, etc. These things do come in the way of pairing 8 hrs a day. So what we do on most of the teams is have core-pairing hours.
For Ex:
08:50 : 09:00 – We have our stand up meeting
09:30 : 12:30 – We have the first core pairing session.
12:30 : 02:00 – People are free to do other stuff and lunch.
02:00 : 03:00 – Any team meetings if required.
03:00 : 05:30 – We have another pairing session.
Sometimes we have another stand up at 5:30.
So in an 8 hr day we at least have 5.5 hrs of pairing.
There is always going to be resistance to pairing. The biggest reason I have found so far in 4 years is, fear of exposing how much they know to others. My theory is, usually junior people are much open to pairing, coz everyone expects that they don‘t know much and they don‘t really have any fear of exposure. On the other hand, people who want to hide in their cubical will always resist it with irrational / unacceptable reasons.
The best thing to do is have open team discussion on this topic. Challenge people in front of the whole team. Ask for facts.
IMHO, Pair programming is not effective in the following cases:
1. If you don‘t have a team room and everyone sitting at the table. If people go back to their cubical and try pairing, it is usually not effective. Most cubicals are built for one person it sit in. Trying to fit 2 people in there, mean one person is always going to be looking over the shoulder of the person driving.
2. If your are not following Promiscuous pair programming. If your pairs are not swapping frequently [at least once a day], then you are going back to old ways of programming. Instead of one person now you have 2 people. So what? You need more pair of eyes. You need collective code ownership and not pair code ownership.
Please note Promiscuous means “Promiscuity is the practice of making relatively unselective, casual and indiscriminate choices.”
Pod cast and Slides.
3. If developers are not involved in estimation and planning
4. If you already have spend more than 10% of your project budget on BIG UPFRONT DESIGN. And if you have architects on the team who don‘t want to pair but just want to create fancy documents and throw it over the wall.
5. If your manager assigns tasks to the pairs
Q 3. Some people want to pair but do not pair well, i.e. though they are looking at the same computer actually they are planning a vacation, i know this may sound ridiculous but it happens. How do you deal with this?
Talk to them. Very very important. Understanding their issues is most important. You cannot afford any communication gap.
Encourage them to try ping-pong pair programming.
Q 4. Some tasks do not seem fit for pair programming at all, they are too routine/mundane to have a pair work on them. Do you see this happening?
I often hear research, reading a book, searching on the net, learning new technology, documentation, etc.
I do most of these along with my pair and I find it really helpful and fast.
For Ex: You are searching for something on the net, go to Google and start entering your search criteria. I often spend a lot of time refining my search criteria. While when I‘m pairing, we discuss the search criteria and always come up with a better search criteria than what I would have come up myself.
Documentation is another very good example. Documentation is very similar to programming to me. There is something in your head, that you want to communicate. By working with a pair, it makes sure what you are documenting/ expressing, is understandable by at least one other person, than just you. You might be making a lot of assumptions that are not clear to other people. Hopefully your pair will challenge some of those assumptions, leading to more understandable documents and hence better quality of the document.
I tend to pair on all these tasks, coz there is some knowledge involved in these tasks. I would like my team members to be aware of how to accomplish the similar tasks later. There could be different ways to accomplish the same task. If a pair works on it, they might come up with a better way to accomplish these tasks.
One of the things I have noticed in the past is, if its a single person trying to do these kind of tasks, they might be motivated to just manually do it and get done with it. Or sometimes, they might spend days together coming up with a framework to accomplish the task. But if a pair is working on it,
A [one of them] might say, “you know what, we might want to create this thing again and again, lets just quickly automate this“.
B might say, “but automating this might take 4 times more time than what we have estimated for this“
A: “Really, I was just thinking of writing an ant target to do this“
B: “Ohh…Yeah that‘s a good idea. But I‘m not very well versed with Ant“
A: “I have done some work with Ant, so I think we can get this done in 30 mins“
B: “Excellent! Lets get rolling”
You see…there is learning involved, quality of end product is much better. Never under-estimate the outcome of 2 brains at work.
