There's been a lot of attention on Twitter to an article by Jon Evans at TechCrunch that takes a fairly broad attack on the agile practice of pair programming, only to advise readers to use their best judgement about it. I find the piece to be a sensationalist attack on a practice that the author doesn't seem to understand. He cites the ineffectiveness* of "brainstorming", which pairing is nothing like; and the dangers of allowing people to hide and let others do the work, which good pairing actually mitigates. Even if you grant his, in my estimation, weakly-supported hypothesis that it harms superstars, it completely misses the accelerated learning and distribution of knowledge that pairing affords agile developers and newbies. The article also misses the natural instinct that we developers have to work on what we find fun and interesting, even if it's not trying to solve the business problem at hand - how many times have you seen a cowboy rewrite working code because s/he didn't like it or because it was a prime candidate for a flashy new technology? Waste like that doesn't happen in good pairs. Neither does finding yourself at the end of a couple of hours having achieved little besides some web surfing, a few personal calls, and having reduced the size of your inbox? Or haven't we all seen great, creative solo work, that isn't what the business needs?
Evans doesn't acknowledge that pairing is a skill that takes practice to get good at, and for some developers getting good at it requires some people to step out of their comfort zones. Rather than his arguments against pairing, I'd like to see an article discussing personal challenges that pairing poses for some developers and the courage that it will take for them to become good pairers, if they want to avail themselves of the benefits of pairing.
* This claim may not even withstand scrutiny: http://bobsutton.typepad.com/my_weblog/2012/01/why-the-new-yorkers-claim-that-brainstorming-doesnt-work-is-an-overstatement-and-possibly-wrong.html
Post a Comment