|dc.description.abstract||The advocates of pair programming claim that it has a number of benefits over traditional individual programming, including faster software development, higher quality code, reduced overall software development cost, increased productivity, better knowledge transfer, increased job satisfaction and increased confidence in the resulting product, at only the cost of slightly increased personnel hours. While the concept of pair programming is attractive, it has some detraction. First, it requires that the two developers be at the same place at the same time. Second, it requires an enlightened management that believes that letting two people work on the same task will result in better software than if they worked separately. Third, the empirical evidence of the benefits of pair programming is mixed. Anecdotal and empirical evidence shows that pair programming is better suited for job training than for real software development. Pair programming is more effective than traditional single-person development if both members of the pair are novices to the task at hand. Novice-expert and expert-expert pairs have not been demonstrated to be effective.
This research proposes a new variant of pair programming called the Collaborative-Adversarial Pair (CAP) programming. Its objective is to exploit the advantages of pair programming while at the same time downplaying the disadvantages. Unlike traditional pairs, where two people work together in all the phases of software development, CAPs start by designing together; splitting into independent test construction and code implementation roles; then joining again for testing.
Two empirical experiments were conducted during the Fall 2008 and Spring 2009 semesters to validate CAP against traditional pair programming and individual programming. Forty two (42) volunteer students, undergraduate seniors and graduate students from Auburn University’s Software Process class, participated in the studies. The subjects used Eclipse and JUnit to perform three programming tasks with different degrees of complexity. The subjects were randomly divided into three experimental groups: individual (Solo) programming group, pair programming (PP) group and collaborative adversarial pair (CAP) programming group in the ratio of 1:2:2. The results of this experiment point in favor of CAP development methodology and do not support the claim that pair programming in general reduces the overall software development time or increase the program quality or correctness.||en