I, Not Robot
Mike has an interesting post about some of his recent experience at a company adopting agile. He seems to have a reasonable amount of skepticism but is willing to try things out, which is good.
One thing Mike touches on with respect to the purpose of pair programming is the fact that developers are different.
Now, it is a fact that individual coders have different talents; some are good at one thing, but not as strong at something else. Some are about the same everywhere. Some are rockstars. And some are morons and couldn’t tie their shoes without looking it up first on ExpertsExchange. Large organizations (the types that have things like “methodologies”) tend to attract few rockstars and lots of mixed talents and assorted riffraff. (I’m not pointing fingers, I’ve worked there too!) Pair programming works well there because it leaves no individual responsible for the output of the team.
This brings up two points.
First, developers can’t be interchanged. You can’t swap out one developer for another and expect the same results. It just isn’t going to happen. Developers are different. People are different. Period. We aren’t robots. We aren’t building 1000 copies of a widget for 8 hours a day. In fact, it is worse than that. Not only do developers not have robotic output consistant with each other, but most aren’t even consistant with themselves from one day to the next.
Second, individual responsibility is a good thing and if pair programming (or anything else) reduces individual responsibility then the output of the team will suffer. We want developers to ‘own’ their code. We want developers to be accountable for what they do. If they don’t care, it will show in the output, regardless of how many developers are working on that piece of output. I’d much rather one developer who takes responsibility for his own code then a pair of programmers that rely on ‘team responsibility’.
For the record, I don’t think the intent of Agile was to reduce developers to robots, but it sure feels that way sometimes.