Pair Programming Isa Waste

"We only hire the best and the brightest engineers here. Why would we want to team them up? That's not the most efficient way to run a business."

-- upper management at my former workplace [a startup company, too]

I spent many a long meeting trying to convince them otherwise. You can't just measure productivity by counting heads, you'll have a hard time getting quality software without some sort of CodeInspection?, etc. I got plenty of smiles and nods, but I still didn't convince them.

I went and tried anyway. I printed out Wiki pages every week, and hung them up on my cubicle wall. PairProgramming, TheSourceCodeIsTheDesign, DrivingMetaphor, WuWei etc. People started listening... and it worked beautifully.

Still, management was in denial that it would be a repeatable success. Our project manager (who really supported me in this) told me that "if management saw TOO many people using these 'crazy XP ideas' they'd put a 'stop to it'".

They never did, but I really have to wonder what caused such an emotional response. I think it is hard to get around the EngineerAsHero mentality (especially since upper management consisted of all hardware engineers).

--StuCharlton

I suspect hardware engineers may have a harder time accepting XP because hardware design still exhibits much of the ExponentialCostCurve for change, which makes BigDesignUpFront a much more reasonable strategy. -- JohnBrewer

Hard numbers for pair programming productivity improvement: http://stsc.hill.af.mil/crosstalk/frames.asp?uri=1996/07/manageme.asp [Look for "Two-Person Team" in bold in the second half.]

The article mostly focuses on management, but does have results from a 1975 FORTRAN project involving five "Two Person Teams". From the article:

: The two-person approach places two engineers or two programmers in the same location (office, cubicle, etc.) with one workstation and one problem to solve. The team is not allowed to divide the task but produces the design, code, and documentation as if the team was a single individual. [...]
: Final project results were astounding. Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 lppm prior to the project. This result is especially striking when we consider two persons produced each line of source code. The error rate through software-system integration was three orders of magnitude lower than the organization's norm. [emphasis added]

Interesting. My first thought would probably be to emphasize it this way:

: Final project results were astounding. Total productivity was 175 lines per person-month (lppm) compared to a documented average individual productivity of only 77 lppm prior to the project. This result is especially striking when we consider two persons produced each line of source code. The error rate through software-system integration was three orders of magnitude lower than the organization's norm. [emphasis added]

When reading and making notes, JeffGrigg noted that PairProgramming gave this project measurable results of...

two working together were slightly over 4.5 times as productive as one working alone.
error rates reduced on the order of one thousand times

Now why was it again that you (Mr. PointyHairedBoss) don't want to achieve results like these?

two working together were slightly over 4.5 times as productive as one working alone.

Isn't this a bit of a skewed conclusion? A more appropriate conclusion would be perhaps "when working in pairs, each person was 2.25 times as productive as when working alone." --JacobCohen

Yes; exactly. But for some audiences you have to learn HowToLieWithStatistics.

A result like this are fairly quoted as "4.5 times productivity with 2 times the headcount ... and with dramatic quality improvements too."

An aside: Sometimes I think I am living in a different world to everybody else. 175 lines of code per person month is productive? If I only produced 175 lines of code per month, I'd soon get the sack! Or am I misreading something? -- ChrisSandow

Perhaps the objections come because it is such a visible and easily controllable point of process. A frightened manager may not be able to see or influence much about software development, but they can by god keep these programmers from wasting time chatting.

I think it's a case of InputsVsOutputs. --JohnBrewer

PairProgramming may be logically more effective (once you run some studies), but it is intuitively less effective. It looks like wasted time. By and large, managers are more intuitive and less logical than software developers. Logic gets developers through the day, since it's all the computer can handle. Intuition, not logic, gets managers through the day, because intuition is better than logic in working with people. It's not surprising that managers tend to go to the intuitive, illogical conclusion. It's part and parcel of the job, not a character flaw.

Perhaps this sort of thing should be an example to show why software development managers have to be a slightly different breed from other managers. I'm waiting for MBA 401: The Care and Feeding of your Geeks

--RobMandeville

CategoryPairProgramming