3 ms·

> The underlying assumption is actually, For any two programmers, no matter how good he or she is, if we get them to sit together, the value of their work will

> The underlying assumption is actually, For any two programmers, no matter how good he or she is, if we get them to sit together, the value of their work will be greater than if they sit apart. Yes, an ASSUMPTION. Not proven. Not studied. An assumption. > There's an implicit assumption there that all bugs take the same amount of time to fix. No there isn't. > Now, I'm about to make a crucial assumption: that Alice and Bob's "difficult tasks" are disjoint, such that what's difficult for Alice is not necessarily difficult for Bob and vice-versa. ... Followed by some anecdata to validate the assumption, followed by "calculations" using hand-wavey numbers. The rest of the article is similarly filled with hand waving, assumptions, strawmen, and outright fabrications. If you have a valid point, use valid reasoning to argue it.

gleenn 7y ago
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.
- deleted 7y ago
  [deleted]

gleenn 7y ago

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.

deleted 7y ago
[deleted]