This post originated from an RSS feed registered with Agile Buzz
by Simon Baker.
Original Post: My take on the perils of pair-programming
Feed Title: Agile In Action
Feed URL: http://feeds.feedburner.com/AgileInAction
Feed Description: Energized Work's blog.
Yesterday I read Matt Stephen's article about the perils of pair programming. Let me prefix what I'm going to say with this: Pair-programming isn't for everyone. It's uncomfortable and scary at first. And when you're used to it it's intensive and bloody tiring.
There's a gazillion reasons why people don't like pair-programming. Some people don't like the intensity of pairing. Others can't sustain the rate of interaction and burn out over time. There's no shame here. What is disappointing is that some people feel exposed when they pair, "the other person is constantly watching what I do and judging me!" They never quite grasp the fact that it's not about them. They're not being tested or judged. It gets worse when egos get in the way. Some people think they're a good programmer until pairing reveals that, actually, they ain't as good as they thought they were. And rather than take it on the chin, knuckle down and look to improve their skills by continuing to pair, they recoil and make some exclamation about why pair-programming is wrong. And then there's the variety of personal habits to contend with.
Successful pair programming is as much about effective soft skills as it is about technical skills. Each person engaged in pairing needs to be sensitive to the other person, and listen effectively and read their body language; be able to convey ideas, engage in constructive disagreement, offer alternatives without judgement or condescension and persuade the other person; have the ability to sense when to offer help and be humble enough to ask for it. It's a shame many programmers struggle with these soft skills.
Pair-programming is a social engagement, a conversation, an exchange of ideas between two people working together to solve a problem incrementally. It's both a technical and social learning experience. Having seen pair-programming work (and I do say, it works), I believe that the design cycle of test-driven development: test-code-refactor is simply more effective when one person is focused on tactical solutions while the other is continuously framing them strategically within the bigger picture of the system.
Ok I haven't said anything new here, so back to the article.
First, I want to make a general comment about the article. When I read it, I heard a lot about the individual and nothing about the team. I know the article is about pair-programming but the practice needs to be viewed within the broader context of achieving agility. And for me the concept of team is a key part to achieving agility.
Matt starts with:
Pairing with a slower programmer isn't merely frustrating for the more productive programmer: it's slowing him/her down, which in turn is slowing the project down, because s/he isn't getting as much done.
Yes, this can be frustrating for the faster programmer. But, quite frankly, he needs to work through it because he knows it's about what the team has committed to and what the team can achieve collectively. It's not about him nor his productivity. All the metrics being tracked on burn-up charts relate to the team's delivery of business value. He should see the time spent with the other person as an investment in the team. The other person will hopefully respond and improve over time, and will eventually bring more to the team and become a more effective partner. When a person is not pulling their weight and is not working constructively with the others to improve, an empowered team will demonstrate some form of self-selection to deal with that person appropriately.
Matt says:
Of course, it isn't the slower programmer's fault. He may be a junior coder, paired up with a senior developer for an hour or two each day in the hope that some of the senior's lifetime-accumulated wisdom and eruditeness may rub off on the little tyke.
What's to say that lifetime-accumulated wisdom and eruditeness makes a senior programmer a good programmer? Both people engaged in a pair can and will learn from each other. Don't under-estimate the fresh perspectives of an inexperienced programmer.
Matt says:
Preferring to have some peace and quiet to program does not a bad programmer make: in fact, I'll stick my neck out and say that this preference is a good indicator of a damn fine programmer.
I agree with everything up to the colon. Just because someone wants to work on his own does not make him a bad programmer. But wanting to work alone is defintiely not a good indicator of a damn fine programmer. A bad programmer might also want to work alone and he might be hacking away at pace, but he will still exhibit bad coding habits and make poor design decisions.
Matt says:
It's indisputable that some pairings work better than others... agile aficionados have an answer: pairs must rotate partners frequently, so that ill-matched/inefficient pairs aren't sat together for too long.
My motivation for encouraging frequent pair-swaps is to promote the sharing of knowledge amongst the team, not to avoid or minimise the effect of ill-matched/inefficientpairs. I'm always interested to observe what happens when a pair involves 2 people with an interesting combination of myers-briggs types. As a coach you watch for these situations and facilitate appropriately.
Matt says:
But crucially, not everyone likes pair programming. Not everyone is naturally extroverted or a social butterfly that will wither away if he doesn't get to chatter to his colleagues for eight hours a day.
It's not as simple as being extrovert or introvert. I've worked with excellent pair-programmers that are introverted. I think there are deeper personality characteristics at play here. For example, having the courage to show vulnerability, fallibility and imperfection, to make mistakes in front of another. And trusting the other person to help and not ridicule or blame. In a trusting relationship, people will communicate.
Matt asks:
So if many good programmers are not naturally inclined to pair program, how do you find the staff?
What's important is that people are willing to try it for a period of time before dismissing it, and give it a fair shot of working. In my experience, people who fit well into an empowered team working in an open and trusting environment usually take to pair-programming. They remain objective and recognise both the benefits and the drawbacks, and then work to adapt and improve how they employ the practice.
Management? No! Coaching, yes! For me, if a team is being managed it's in a command and control environment and is not empowered. I haven't yet seen a team achieve agility in such an environment.
Matt goes on to say:
Making [pair-programming] mandatory 100% of the time, and expecting a mixed-ability team to sort out their differences in abilities and still be highly productive, is just asking for trouble.
What's asking for trouble is making people do something. We're back to management. Command and control elicits compliance to enforced processes. When I work with a team I facilitate a chartering session in which they decide on the working practices to be used. The team I was working with used pair-programming for all the code destined to hit the subversion repository (and ultimately the production servers). This equated to around 95% of the time they spent programming. When the project started, not everyone had tried pair-programming and some were nervous. But during the chartering session they all decided that they wanted to try it for 4 weeks. Now they're hooked. The team decides how it wants to employ pair-programming. As the coach, I talk to them about the risks of not doing it and simply ask them not to dismiss it without first trying it.
One final thing. Surely a continuous code review performed in context and privy to the many small design decisions made on route to the solution has got to be more effective and have a greater influence on the quality of the implementation than a code review performed after the solution is attained?
Previous Topic
