%0 Journal Article
%T Collaborative-Adversarial Pair Programming
%A Rajendran Swamidurai
%A David A. Umphress
%J ISRN Software Engineering
%D 2012
%R 10.5402/2012/516184
%X This paper presents a study called collaborative-adversarial pair (CAP) programming which is an alternative to pair programming (PP). Its objective is to exploit the advantages of pair programming while at the same time downplaying its 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. An empirical study was conducted in fall 2008 and in spring 2009 with twenty-six computer science and software engineering senior and graduate students at Auburn University. The subjects were randomly divided into two groups (CAP/experimental group and PP/control group). The subjects used Eclipse and JUnit to perform three programming tasks with different degrees of complexity. 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 software development duration, overall software development cost or increases the program quality or correctness. 1. Introduction One of the popular, emerging, and most controversial topics in the area of software engineering in the recent years is pair programming. Pair programming (PP) is a way of inspecting code as it is being written. Its premise¡ªthat of two people, one computer¡ªis that two people working together on the same task will likely produce better code than one person working individually. In pair programming, one person acts as the ¡°driver¡± and the other person acts as the ¡°navigator.¡±The driver is responsible for typing code; the navigator is responsible for reviewing the code. In a sense, the driver addresses operational issues of implementation and the observer keeps in mind the strategic direction the code must take. Although the history of pair programming stretches back to punched cards, it emerged as a viable approach to software development in the early 1990s when it was noted as one of the 12 key practices promoted by extreme programming (XP) [1]. In recent years, industry and academia have turned their attention and interest toward pair programming [2, 3], and it has been widely accepted as an alternative to traditional individual programming [4]. Advocates of pair programming claim that at the cost of only slightly increased personnel hours, pair programming offers many benefits over traditional individual programming, such as faster software development, higher quality code, reduced overall software development cost,
%U http://www.hindawi.com/journals/isrn.software.engineering/2012/516184/