pair programming is busted

this is part of a series of posts i wrote for my software engineering course at university of texas.

this week in my software engineering course we covered a number of topics including pair programming. we had to read three different texts, all of which extolled the practice, and we were assigned a project where we actually engaged in pair programming.

after all of this, i think the arguments fall short. if pair programming is as great as these sources claim, then why is it so rare in the industry? "but there are studies!" you say. "but, but... kent beck said so!" you cry. let's check some of them against reality:

don't get me wrong, i really enjoyed working with my partner on the project. beyond that i think there are many cases where it's completely appropriate for two developers to work together on the same problem. but on the whole i find it similar to dogmatically applying TDD or side-effect-free function programming: it just doesn't seem grounded in reality.

in a perfect world, we'd always write our unit tests first, it'd be easy to find a job writing haskell, and we'd pair program everything (a gender-inclusive-bromance, if you will). but as long as i'm living here on earth, i'll apply these principles with a grain of salt.

blog comments powered by Disqus
© aaron stacy 2013, all rights reserved