I don't mind a good critique of pair programming -- it deserves a hard look to think about its pros and cons -- but I do take issue with a paper written in this

I don't mind a good critique of pair programming -- it deserves a hard look to think about its pros and cons -- but I do take issue with a paper written in this way. I want to mention the opening line in the introduction: "The pair programming method could only exist in an industry that does not measure well and does not understand economics." This argument is speculative and unpersuasive. Speaking of measurement, I take issue with this paper because it suggests that lines of code (LOC) is a good metric. The author demonstrates a lack of economic savvy by writing, "As can be seen from table 1 the economics of pair programming are severely negative." That table uses lines of code (LOC) as the key metric. There are so many problems with the choice of such a wrongheaded metric. First, writing better software often involves writing less code! Second, as a commenter points out, knowledge transfer is very important. Third, pair programming may build team cohesion. Many industries use variations of pair programming, as the author recognizes. That said, I think the author fumbles in suggesting that quarterbacks trading time is similar to pairing. I wonder why the author didn't look at apprenticeships in manufacturing, where skills are demonstrated in a hands-on way. Finally, as a model-builder myself, it pains me to see weak, flawed models baked into papers such as this. Take this section of text: "Table 1 is extracted from a pair-programming calculator developed by the author. It allows researchers to input a number of variables including staff compensation, application size in lines of code, and coding speeds for both pairs and individual programmers." Such language, to me, makes it appear that the author is trying to make his claims seem "mechanical" -- just the matter of turning a crank and running some calculations. Such a claim is silly and a sham, of course. The choice of what to measure and how to weigh it is central. This paper makes no serious attempt to promote such a discussion. In summary, this paper did not make a serious attempt to understand the true (economic, yes!) value of pair programming, in my opinion. If I were to guess, the author may well have had his conclusion in mind before writing the paper or doing his research.