4 ms·

I'm certainly no opponent of pair programming, but its proponents often seem not to address the 0th order argument against it: the parallel/series problem. To c

by mhartl 17y ago

I'm certainly no opponent of pair programming, but its proponents often seem not to address the 0th order argument against it: the parallel/series problem. To complete tasks A and B, Alice and Bob can finish them in parallel if they work alone, but can finish them only in series if they work together. This means that, for equal-sized tasks, solo programming is a priori twice as productive as pair programming. I'm perfectly willing to believe that the benefits of pairing can overcome this factor (and more), but that's a strong claim and requires strong evidence.

rick_2047 17y ago
I find a flaw in your reasoning sir, you are making a rather large assumption that in pair programming both the participants must have same set of skills. Its rather the opposite I think, they must actually have mutually exclusive skill sets. Like one should have a problem solving mind(navigator) and the other should have a solution implementing mind (driver). Thus if they both work parallel they would actually take more time in solving the same problem rather than if they work in series. For an example if I want to make bio informatics program I would rather be a driver and code and have a navigator who has skills in the other parts of the program.
AndrewDucker 17y ago
In my experience, working as a pair produces bug-free code at least twice as fast as working singly. The person not typing spots bugs a lot better than the person at the keyboard, and having someone to bounce designs off of means you don't head down the wrong path with them.
gvb 17y ago
In my experience (24 years in a large company doing a lot of large projects), the coupling of different pieces of the program is severely underestimated. The result is that The Plan lays out the schedule with Alice and Bob working in parallel, but in reality they end up requiring a lot of interaction before the project is done. Typically in a large project, Alice and Bob work independently but make different assumptions and have to rework a significant amount of their code when they finally get together to integrate their two parts. In my experience, large teams can shrink calendar schedule time by brute forcing the dependency failures. The trade-off to achieve schedule compression is substantial inefficiencies and often a loss of quality and maintainability. I am convinced that a lot of schedule slippage in large projects is due to incorrect assumptions with respect to the independence of the pieces. While it is possible to compress the schedule this way, all schedule compression that exceeds the true parallelism in the project requires exponentially increasing effort to overcome the inefficiencies due to the coupling. This is behind Brook's Law http://en.wikipedia.org/wiki/Brookss_law http://en.wikipedia.org/wiki/Brookss_law "2. Communication overheads increase as the number of people increases." Communication overhead is the indication of coupling of the pieces. If Alice and Bob's pieces were truly independent, they would not need to communicate and Brook's Law would not apply. The physical analogy to the effort required to shrink calendar time is the "hull speed" of boats. http://en.wikipedia.org/wiki/Hull_speed http://en.wikipedia.org/wiki/Hull_speed and http://en.wikipedia.org/wiki/Wave_making_resistance http://en.wikipedia.org/wiki/Wave_making_resistance. While it is possible to "escape your bow and stern waves" (i.e plane), it takes an exponential amount of power to do so. (The first wikipedia page links to another nice explanation: http://www.antrimdesign.com/articles/hullspeed.html. http://www.antrimdesign.com/articles/hullspeed.html.)

by mhartl 17y ago

rick_2047 17y ago

I find a flaw in your reasoning sir, you are making a rather large assumption that in pair programming both the participants must have same set of skills. Its rather the opposite I think, they must actually have mutually exclusive skill sets. Like one should have a problem solving mind(navigator) and the other should have a solution implementing mind (driver). Thus if they both work parallel they would actually take more time in solving the same problem rather than if they work in series. For an example if I want to make bio informatics program I would rather be a driver and code and have a navigator who has skills in the other parts of the program.

AndrewDucker 17y ago

In my experience, working as a pair produces bug-free code at least twice as fast as working singly. The person not typing spots bugs a lot better than the person at the keyboard, and having someone to bounce designs off of means you don't head down the wrong path with them.

gvb 17y ago

In my experience (24 years in a large company doing a lot of large projects), the coupling of different pieces of the program is severely underestimated. The result is that The Plan lays out the schedule with Alice and Bob working in parallel, but in reality they end up requiring a lot of interaction before the project is done. Typically in a large project, Alice and Bob work independently but make different assumptions and have to rework a significant amount of their code when they finally get together to integrate their two parts. In my experience, large teams can shrink calendar schedule time by brute forcing the dependency failures. The trade-off to achieve schedule compression is substantial inefficiencies and often a loss of quality and maintainability. I am convinced that a lot of schedule slippage in large projects is due to incorrect assumptions with respect to the independence of the pieces. While it is possible to compress the schedule this way, all schedule compression that exceeds the true parallelism in the project requires exponentially increasing effort to overcome the inefficiencies due to the coupling. This is behind Brook's Law http://en.wikipedia.org/wiki/Brookss_law http://en.wikipedia.org/wiki/Brookss_law "2. Communication overheads increase as the number of people increases." Communication overhead is the indication of coupling of the pieces. If Alice and Bob's pieces were truly independent, they would not need to communicate and Brook's Law would not apply. The physical analogy to the effort required to shrink calendar time is the "hull speed" of boats. http://en.wikipedia.org/wiki/Hull_speed http://en.wikipedia.org/wiki/Hull_speed and http://en.wikipedia.org/wiki/Wave_making_resistance http://en.wikipedia.org/wiki/Wave_making_resistance. While it is possible to "escape your bow and stern waves" (i.e plane), it takes an exponential amount of power to do so. (The first wikipedia page links to another nice explanation: http://www.antrimdesign.com/articles/hullspeed.html. http://www.antrimdesign.com/articles/hullspeed.html.)