June 13, 2013 Draft 1.0
Pair programming is a new method in which two programmers share an office and a terminal and take turns coding while the other watches and comments. The method is often associated with flavors of agile development such as extreme programming, although it is used with other methods too.
Pair programming costs about 2.5 times as much as one programmer working alone. There are no significant quality benefits compared to a single programmer who uses static analysis and inspections.
Pair programming is the opposite of lean development; it is bloat. There are a total of 116 occupation groups employed by large companies. As many as 50 occupations work on large systems. It is unknown why only programmers were selected to be doubled.
Capers Jones, CTO and Vice President
Copyright 2013 by Capers Jones.
All Rights Reserved.
The pair programming method could only exist in an industry that does not measure well and does not understand economics.
In pair programming two programmers share an office and a work station and take turns coding and observing. The coder is called the “driver” and the observer is called the “navigator.” The two switch roles frequently.
The literature and experiments with pairs are deficient because they do not consider all of the variables that can affect the outcome of pairs versus single programmers. Some of the topics that should have been included but were not are:
- Single programmers who use static analysis
- Single programmers who use inspections
- Single programmers who use both static analysis and inspections
- Expert single programmers compared to average pairs
- Expert pairs compared to average single programmers
- Novice single programmers compared to average pairs
- Novice pairs compared to expert single programmers
- Novice single programmers compared to novice pairs
- Average single programmers compared to average pairs
- Expert single programmers compared to expert pairs
Many of the studies appear to take random pairs and compare the results to random single programmers without either side using static analysis or inspections. This is not a realistic comparison. Both sides should use at least static analysis.
Most of the studies are very small scale. There is zero literature on using pairs for large systems which might have 500 or more programmers. No company is going to hire 500 additional programmers without substantial economic reason. Even if they tried, it is unlikely that 500 capable personnel could be hired to work as pairs.
Most of the studies on pair programming assume that both the pairs and the single programmers do their own testing and seem to stop at unit test. There is little information about the impact of certified test personnel. Would testing by certified professional testers for function test, regression test, component test, performance test, and system test change the results? Would there be pairs of certified testers too?
All of the studies are based solely on programmers and ignore all other software occupations such as business analysts, architects, testers, quality assurance, data base analysts, project managers, and any of the total of 116 occupation groups associated with software development and software maintenance.
On large software systems there may be as many as 50 occupation groups including business analysts, data base analysts, architects, designers, quality assurance, test personnel, technical writers, project office staff, managers, and many more. Why not double some or all of these other personnel?
Negative Economics of Pair Programming
Average pairs of programmers code about 15% more slowly than average single programmers.
This reduction in speed would only have positive value if defects were reduced almost to zero but that is not the case. Also, requirements and design defects outnumber code defects on large systems and pair programmers have little impact on non-code defects.
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. Table 1 shows a typical pattern for average pairs and average individual programmers for 1000 code statements:
Table 1: Pair Programming vs. Single Programming Costs and Schedules
Application size in LOC:
|Single coding speed in LOC per hour:||20|
|Pair coding speed in LOC per hour:||15|
|Single Programmer||Pair Programming||Difference|
As can be seen from table 1 the economics of pair programming are severely negative. Pair programming costs were $7,576 versus $2,841 for an increase of over 266%. Pair programming schedules were 11.11 days as opposed to 8.33 days for an increase of 133%.
Unless the quality results for the pair approached zero defects and the quality results for the individual programmer were very poor there would seem to be no economic justification for pair programming.
Unfortunately the quality data from the pair programming literature is not adequate because it omits the impacts of inspections and static analysis. Table 2 shows the quality results of a single programmer using both static analysis and inspections versus a pair that uses only testing:
Table 2: Pair Programming vs. Single Programming Quality
|Static analysis %||50%|
If the individual programmer used a combination of static analysis and inspections, then the quality would be much better than the pair. However this is not a fair comparison because the pair could also use static analysis.
The point of table 2 is that the literature on pair programming fails to include the potential impacts of either static analysis or inspections on quality. If a single programmer uses static analysis and inspections the quality results will be much better than the pair. If both the pair and the individual use static analysis, the quality results will be about the same but the pairs are still more than 250% as expensive.
Ranges of Programming Experience Levels
Programmers are not all equal in experience. Let us assume three plateaus: expert, average, and novice for both the individual programmers and the pair programmers. These ranges yield nine possible combinations:
- Single Programmer
- Pair Programmers
Table 3 shows the results from these nine combinations for coding costs for 1000 code statements at a cost of $7,500 per month:
Table 3: Single and Pair Programming Experience Levels
It is obvious from table 3 that the best economic results do not come from pair programming but rather from hiring and using expert single programmers. Since only about 10% of the programming population can be classed as “experts” it is also obvious that pair programming dilutes the pool of expertise without adding any economic value.
Because the main claim for pair programming is improved quality, table 4 shows the quality results from individuals and pairs at expert, average, and novice skill levels. Table 4 assumes static analysis followed by unit testing. Only code bugs are shown in table 4: requirements and design bugs are hard to remove by either static analysis or by testing. Inspections are the best technology for removing front-end defects in requirements and design.
Table 4 assumes 1000 source code statements:
Table 4: Software Quality Levels by Experience
In the case where both the pair and the individual programmer are experts, pair programming has an advantage. In cases where the individual programmer is an expert and the pairs are either average or novice, the individual programmer has the quality advantage. But it should be remembered that the pair is still much more expensive than the individual.
For quality as well as costs, the best long-term strategy is not pair programming but selecting top experienced individual programmers.
For quality as well as costs the percentage of the programming population who might be viewed as “expert” is only about 10%. Here too using pair programming would dilute the pool of available experts.
Harmful Consequences of Divided Authority
To date the concept of “pairs” has only been applied to programmers. Because divided authority has been shown to be quite harmful in many other fields, doubling personnel is something to be cautious about.
The software industry employs a total of 116 different occupation groups. To date there is no data or literature on other kinds of pairs such as:
- Pairs of business analysts
- Pairs of architects
- Pairs of designers
- Pairs of testers
- Pairs of quality assurance
- Pairs of cost estimation specialists
- Pairs of technical writers
- Pairs of project managers
In many kinds of work divided authority has been shown to be harmful. For example divided authority in military campaigns has led to many famous military disasters such as the battle of Cannae where Carthage defeated a Roman army with divided command.
For some kinds of work pairs have been shown to be helpful:
- Airline pilots and copilots
- Scuba diving with pairs
- Authoring some but not all books
- Police patrol units in hazardous locations
For other kinds of work pairs have been shown to be quite harmful:
- Military commands
- Corporate CEO level executives
- Medical practices for individual patients
- Professional football with two quarterbacks sharing playing time
Pair programming was an interesting experiment, but not a method that should have been rushed into production use without a great deal more due diligence than has actually occurred.
REFERENCES AND ADDITIONAL INFORMATION
Jones, Capers; Software Engineering Best Practices; McGraw Hill, 2010.
Jones, Capers; The Economics of Software Quality, Addison Wesley, 2011.