How do you justify pair programming's cost when the evidence for it is contested?

## Meet the objection as stated The objection is arithmetic: two engineers, one change, so the change costs twice as much. Any answer that dodges this loses the room. The correct move is to accept the framing and then argue that the denominator is wrong — you are not buying keystrokes, you are buying a smaller amount of rework, defects caught earlier, and knowledge held in more than one head. ## Be honest that the evidence is contested There is a real research literature on pair programming, and it does not settle the question. Studies vary in ways that plausibly change the result: - **Participants.** Much of the early work uses students on short exercises; teams doing sustained work on a large unfamiliar system are a different population. - **Task size and duration.** A one-hour exercise and a three-month feature exercise different mechanisms. - **Style.** Ping-pong, strong-style and "two people at one screen with no rules" are not the same intervention, and are often not distinguished. - **Outcome definition.** Defect counts, defect escape rate, effort, elapsed time and quality ratings are all reported, and a result can be positive on one while negative on another. The result is that reported effects on effort and on defect rates run in both directions across studies. A candidate who confidently quotes a fixed figure — "pairing costs fifteen percent more and halves defects" — is quoting one study as if it were a law. The stronger position is to say the literature is mixed, name why, and move the argument onto ground you control. The same discipline applies to related folklore. The claim that defects get an order of magnitude more expensive at each later stage is widely repeated and widely disputed in its precise form; leaning on it to sell pairing puts a contested number underneath a contested practice. ## Argue from a bounded local trial What a lead can actually offer is evidence from this team, on this system, over a bounded period, with the signals agreed before it starts. Worked shape, on an 11-person team owning a hospital appointment scheduler: - **Scope.** Pair on the two highest-risk items per iteration — reversibility and blast radius decide which — and leave everything else alone. Not a blanket mandate. - **Duration.** Nine iterations, decided up front, so it cannot be cancelled the first time a week looks slow. - **Signals, agreed in advance.** Defects escaping from the paired area; elapsed days from a new joiner's start to their first unaided change there; the number of areas exactly one person can safely change; how long a finished change waits before someone else looks at it. - **Read the result honestly.** Suppose escapes in that area fall from 17 to 6 while total items delivered drop about 12%. That is suggestive and it is not proof — nothing was controlled, the team also got more familiar with the area over nine iterations, and the count is small. Say so. A lead who presents an uncontrolled before-and-after as causal has just taught their organisation to distrust the next measurement too. ## Do not let throughput be the only measure Items completed is the measure most readily available and the one pairing is structurally worst on, because two people are producing one stream. Choosing it alone answers the question before it is asked. The counter is not to hide it — report it — but to insist that the decision is made against the full set of agreed signals, including the ones that only appear later. ## Say what pairing does not replace This is the part that separates an advocate from an engineer with judgement: - **Automated checks and the pipeline.** A pair is two people with one shared blind spot and no memory of last month's regressions. - **An independent look by someone who was not in the room.** The pair's shared context is exactly the thing an outside reader does not have, which is why they see different problems. - **Written decisions.** The pair's shared understanding is undocumented and evaporates, including for the two of them. - **Specialist attention.** Depth in security, performance or accessibility does not appear because two generalists sat together. - **Clear requirements and a working environment.** Two people can build the wrong thing efficiently, and pairing on a broken environment simply wastes two people. ## Set it as a default, not a mandate A mandate produces compliance behaviour: sessions held because they are required, with one person driving and the other on their own screen. A default for a named class of work, with a stated reason and a review date, keeps the practice honest and keeps the argument open — which, given that the general evidence really is contested, is the intellectually defensible place to stand.