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,
References
[1]
K. Beck, Extreme Programming Explained: An Embrace Change, Addison-Wesley, 2000.
[2]
E. Arisholm, H. Gallis, T. Dyb？, and D. I. K. Sj？berg, “Evaluating pair programming with respect to system complexity and programmer expertise,” IEEE Transactions on Software Engineering, vol. 33, no. 2, pp. 65–86, 2007.
[3]
G. Canfora, A. Cimitile, F. Garcia, M. Piattini, and C. A. Visaggio, “Evaluating performances of pair designing in industry,” Journal of Systems and Software, vol. 80, no. 8, pp. 1317–1327, 2007.
[4]
M. M. Müller, “Two controlled experiments concerning the comparison of pair programming to peer review,” Journal of Systems and Software, vol. 78, no. 2, pp. 166–179, 2005.
[5]
J. D. Wilson, N. Hoskin, and J. T. Nosek, “The benefits of collaboration for student programmers,” in Proceedings of the 24th SIGCSE Technical Symposium on Computer Science Education, pp. 160–164, February 1993.
[6]
J. T. Nosek, “The case for collaborative programming,” Communications of the ACM, vol. 41, no. 3, pp. 105–108, 1998.
[7]
L. Williams, R. R. Kessler, W. Cunningham, and R. Jeffries, “Strengthening the case for pair programming,” IEEE Software, vol. 17, no. 4, pp. 19–25, 2000.
[8]
C. McDowell, L. Werner, H. Bullock, and J. Fernald, “The effects of pair-programming on performance in an introductory programming course,” in Proceedings of the 33rd SIGCSE Technical Symposium on Computer Science Education, pp. 38–42, Cincinnati, Ky, USA, March 2002.
[9]
S. Xu and V. Rajlich, “Empirical validation of test-driven pair programming in game development,” in Proceedings of the 5th IEEE/ACIS International Conference on Computer and Information Science (ICIS '06). In conjunction with 1st IEEE/ACIS International Workshop on Component-Based Software Engineering, Software Architecture and Reuse (COMSAR '06), pp. 500–505, July 2006.
[10]
J. Nawrocki and A. Wojciechowski, “Experimental Evaluation of pair programming,” in Proceedings of the European Software Control and Metrics Conference (ESCOM '01), pp. 269–276, ESCOM Press.
[11]
J. Vanhanen and C. Lassenius, “Effects of pair programming at the development team level: an experiment,” in Proceedings of the International Symposium on Empirical Software Engineering (ISESE '05), pp. 336–345, November 2005.
[12]
M. Rostaher and M. Hericko, “Tracking test first programming—an experiment, XP/Agile Universe,” LNCS, vol. 2418, pp. 174–184, 2002.
[13]
H. Hulkko and P. Abrahamsson, “A multiple case study on the impact of pair programming on product quality,” in Proceedings of the 27th International Conference on Software Engineering (ICSE '05), pp. 495–504, St. Louis, Mo, USA, May 2005.
[14]
D. Wells and T. Buckley, “. The VCAPS project: an example of transitioning to XP.,” in Extreme Programming Examined, chapter 23, pp. 399–421, Addison-Wesley.
[15]
K. M. Lui and K. C. C. Chan, “Pair programming productivity: Novice-novice vs. expert-expert,” International Journal of Human Computer Studies, vol. 64, no. 9, pp. 915–925, 2006.
[16]
K. Boutin, “Introducing extreme programming in a research and development laboratory,” in Extreme Programming Examined, chapter 25, pp. 433–448, Addison-Wesley.
[17]
M. Fowler, Refactoring: Improving the Design of Existing Code, Addison-Wesley, 1999.
[18]
W. S. Humphrey, PSP(sm): A Self-Improvement Process for Software Engineers, Addison-Wesley, 2005.
