4 ms·
I actually think pair programming cons/benefits is part of a larger pattern that I call "management overhead". The premise is any practice implemented to increa
by mattiask 15y ago
I actually think pair programming cons/benefits is part of a larger pattern that I call "management overhead". The premise is any practice implemented to increase general quality risk being offset by decreased productivity of the top performers.
If you have skilled developers they will work more efficiently the less "management overhead" that is put upon them (processes, checklists, methodologies etc). They will simply self-regulate and a large amount of output of high quality. As the skill/experience of the developers in an organization drops management typically implements practices to better ensure quality. While providing checks and balances for the lowest denominator these will also typically slow down the best.
This is especially nefarious when you consider that a "great" programmer can be 10x (or more) as efficient as an average one. That's probably because they developed habits that make them so, and now you risk meddling with those habits. Making a 10x as efficient programmer 20% less productive can be costly.
The most insidious thing about this as top performers typically can stomach only so much "crap" that slow them down before leaving for another job. Which leaves the organisation with even less skilled workers that need even more "overhead" to control which in turn results in even more "good" employees leaving. Iterate a couple of years and you have an organization where it is very hard to do anything wrong but also almost impossible to get anything done because of all the committee's, best practices, etc
Of course pair programming is going to slow the best programmers down without adding much benefit. On the other hand for bad to average programmers pair programming will probably result in better code with will offset the reduced efficiency. From an organizational standpoint pair programming will reduce dependency on any one programmer.
It's up to every company to decide which trade-offs they're willing to make and balance that against the kind of employee's they have. Some lightweight practices might actually be beneficial even for the top performers but they do take some serious consideration to get right.
If you can manage it, hire really good developers and get out of their way.
- skrebbel 15y agoyour entire point is based on that 10x productivity rule. it keeps popping up. Is it just someone's gut feeling turned into an urban myth or have real studies been done?
- mattiask 15y agohttp://forums.construx.com/blogs/stevemcc/archive/2011/01/09/origins-of-10x-how-valid-is-the-underlying-research.aspx http://forums.construx.com/blogs/stevemcc/archive/2011/01/09...
- mynameishere 15y agoThe 10x comes from the fact that you have 10 fingers. The real number is going to depend wildly upon the context. I've been on projects in which some members contributed zero--and so the ratio is NaNx. On the other hand, if you're writing COBOL crud, the fastest typist will typically be the most productive.
- georgemcbay 15y agoI've been on projects (and I'm sure I'm not alone in this) in which some members contributed negative value. To contribute zero a bad programmer would have to just sit around and reddit all day or whatever. Once the bad programmer starts writing code he is almost surely a net negative since eventually someone is going to have to rewrite his code and unless the code is completely decoupled from everything else, the time required to do that rewrite will exceed the time it would have taken if the bad programmer had never written any code at all.
- mietek 15y agoFred Brooks writes in "The Mythical Man-Month": "Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements! In short the $20,000/year programmer may well be 10 times as productive as the $10,000/year one. The converse may be true, too. The data showed no correlation whatsoever between experience and performance. (I doubt if that is universally true.)"
- squirrel 15y agoAt TIM Group, I've followed the advice in your last sentence by hiring the very best developers I could possibly find and imposing minimal "management overhead". Interestingly, at some point they tried pairing, and decided it made them much _more_ productive; they continue to use it extensively even though it is not at all required (these days it is a cultural norm, but not dictated practise). Just a single experience - a proper academic study would be very interesting if someone could manage it - but it doesn't seem to match your theory.
- mattiask 15y agoI'm sure there are developer pairings and scenarios where pair programming indeed would be beneficial. The point is that in your case the developers where free to themselves test and evaluate it's efficiency and then chose whether to use it. If that's the case then of course you should go with pair programming. That's different however from mandating pair programming where they'd have to use it whether or not it fitted them personally or that the pairing worked out. My point is not as much about specific practices but rather about mandatory ones.