Agile in Action - A Touch of Pair Programming
As a consultant, I am pulled in two seemingly opposing directions in regards to new technology. To be a good consultant, particularly at my company Clarity, you have to be engaged with technology. Reading, talking about, working with new technology is what keeps us fresh and relevant. Here I'm using technology to mean more then just languages or libraries, I also mean the processes and techniques of delivering quality software solutions. The "opposing" force I mentioned earlier is that we have to focus relentlessly on delivering the particular project we're on, with its particular timelines and constraints.
So while I constantly am tinkering with technology in my spare time, I have a much higher bar for what I'd include in my project work. For every upside something new promises, I have to decide if it outweighs the downside or risk to the project. With that said, for the past six months plus, I've been working in product development, so outside the context of my regular on site, client engagement. Our team still cares about the quality of our deliverable, but there is more freedom to experiment with new technology. Using my expanded definition of technology, our team has been experimenting with the new (to us) technology of agile processes.
One of these processes is pair programming. Unfortunately, to the skeptic, a process where two people work together on the same machine on the same task, probably brings the following images to mind:
The Guy Driving
The Other Dude
This is a mistaken view. First off, having worked previously in corporate IT, I can assure you that people are quite capable of doing nothing all day all by their lonesome. Second, we all value pair programming. Don't believe me? Think about what you do when you are working on a particularly nasty bug or making a big architectural decision. You don't usually do that alone, you bring in at least one other trusted person to help out, to bounce ideas off of. I've over simplified here, this is not what agile adherents really mean by pair programming. As an agile practice, pair programming is the predominant mode of work for developers. What I just described is just plain old collaboration. Nevertheless, it is important to point out that the argument is not about whether or not two people working together produce better results, it is about how often they should work together.
Within our product team, we have not moved to pair programming for every task. But we have been using it more extensively then I have before. We've found it surprisingly effective over the past few weeks. In pair programming sessions each lasting a few hours, I and another team member were able to quickly get two components going from design to implementation. I was thrilled with the give and take as we reined in, revised and rejected each others' ideas as necessary. By the end of it, I was mentally worn out, but in a good, kind of post work out muscle burn type of way.
With some hindsight, I think the key to this success was that we were truly peer programming, not just pair programming. There was no project role hierarchy to make one of us hesitant to correct the other, we have similar levels of tech skills and experience so we could keep up with each other and perhaps most importantly we respected each other. Respect means we take each other seriously and actually think about what the other one is saying or coding. This level of engagement helps both sides of the pair get more of out of the experience. Lack of respect plus malice is contempt, which obviously will not work well, but even lack of respect without dislike is often expressed as indifference or pity. Neither one is going to help the pair be more productive then its parts.
Moving forward, I plan to use pair programming more often within our team. I am not ready to take the leap and say we should use it all the time. Part of the software development life cycle always involves some drudgery, linking up simple UI's, writing DB scripts, fixing a simple bug and the like. These tasks might be more pleasant with a partner, but the possible gains in efficiency seem minimal.
Relevant Links
http://xprogramming.com/xpmag/whatisxp#pair
http://menloinnovations.com/blog/?p=399
http://stackoverflow.com/questions/291630/does-pair-programming-work