While it's easy to through around words like anecdata and poke at this article for not having hard data, I simply don't think you'll be satisfied because measur

While it's easy to through around words like anecdata and poke at this article for not having hard data, I simply don't think you'll be satisfied because measuring productivity and value delivered are incredibly hard to quantify. I think this article is wholly reasonable in it's approach as attempting to show with some back-of-the-envelope math and some hand wavy explanation that it is, in fact, possible for the economics of pair programming to work. Having another person try and explain the many complicating factors is exactly what I need someone to have if I want to convince my organization that it is perfectly reasonable to try and no you're productivity won't be cut in half. I did pair programming at two different companies full-time, one was over 200 people and that was one of the most productive companies I've ever worked at, hands down. That is also highly anecdotal, but I know it's true because I did it for 5 years and also have seen what it looks like without it for at least as many. It doesn't work for everyone. Some organizations just attract better people and that is a confounding factor. Remote pairing is hard. All these things are true, but if I want to try it at my next company, as I'm doing right now, I need articles like this to prove I'm not crazy, and yes, it's worth trying if you have problems with communication, or want to train young developers, or learn something new, or reduce bug rework from poor code reviews. It's a very useful method of developing software and I'm happy this guy made an attempt to quantify it, however poorly, because software is just a hard thing to quantify.