Pair Programming
Joel Spolsky recently linked to an incredible long rant by Steve Yegge, “Good Agile, Bad Agile.” I admit that, after reading for a while, I just skimmed it. I’m very interested in agile software development and could write all day about it. Instead, I’m just going to talk about Pair Programming. If you read Steve’s article, you probably got to this section:
Well, people pretty quickly demonstrated that XP was a load of crap. Take Pair Programming, for instance. It’s one of the more spectacular failures of XP. None of the Agileytes likes to talk about it much, but let’s face it: nobody does it. The rationale was something like: “well if ONE programmer sitting at a terminal is good, then TEN must be better, because MORE is ALWAYS better! But most terminals can only comfortably fit TWO programmers, so we’ll call it PAIR programming!”
While I’m a proponent of agile software development, I’ve never been a fan of XP. That doesn’t mean that I dismiss XP out of hand. Instead, I steal those aspects that resonate with me and incorporate them into my methodology toolbox. Of course, Steve is obviously exaggerating for effect, but you may not realize this unless you read most of the rest of his post and get to this section:
Teams are always situated close together in fishbowl-style open seating, so that pair programming happens exactly when it’s needed (say 5% of the time), and never otherwise.
Steve and I agree on this point. There are situations when pair programming is effective. I’ve used it a handful of times in my career and, like formal code reviews, the benefit is education more than quality. For example, I’ve found that if a junior developer who isn’t familiar with a framework or technology sits down at a computer with a senior developer who is intimately familiar with the framework and they write some code together, the junior developer will learn the framework much faster than working on their own and asking questions as needed.
Have developers been doing this long before the advent of XP? Of course. Just because a technique is adopted by a methodology and leveraged in an extreme fashion, it doesn’t mean that the technique is, all of sudden, no longer useful.
There are a huge variety of agile software development techniques and they are each additional tools in developer’s toolbox. Each team working on a project at a specific instant in time benefits most for a methodology unique to their situation. These techniques aren’t silver bullets or golden hammers, just tools lying in the toolbox that, like any tools, can be used or misused. Or maybe I’m just infected with the agile virus….
BTW, for a general, and less extreme, introduction to agile software development, I highly recommend Agile Software Development
