Published in IET Software Received on 5th April 2007 Revised on 3rd March 2008 doi: 10.1049/iet-sen:20070035 ISSN 1751-8806 Software process fusion by combining pair and solo programming K.M. Lui K.C.C. Chan Department of Computing, The Hong Kong Polytechnic University, Hunghom, Hong Kong, People’s Republic of China E-mail: cskmlui@comp.polyu.edu.hk Abstract: The role of pair programming in software development is controversial. This is due partly to the relatively unclear benefit of pair programming over solo programming. There have been arguments either way and there have been studies to show that one is more cost-effective than the others. Rather than investigating into pair vs. solo programming here, we present a new process model combining both together. This paper argues and shows, with two case studies, that the fusing of pair and solo programming processes may actually be better than adopting either alone. In the proposed model called Software Process Fusion (SPF), a donor and a recipient process can be defined and if some transfer conditions are met, one process can be converted into another to achieve tasks with minimal costs. The transfer conditions we define is related to a Software Fusion Ratio (SFR). SFR can be used to evaluate the effectiveness of an SPF model. In our case studies, we observed that, with SPF, programmers would design solution patterns of their own in pairs and then use these patterns to build sub-modules in solos. We conclude that SPF can be a more effective approach to increase productivity of less experienced programmers. 1 Introduction Pair programming (PP) is concerned with two developers sitting together and collaborating with each other on a single computer [1]. One programmer, called the driver, controls the keyboard and implements the program, whereas the other, the observer, continuously examines the work, identifying defects and thinking ahead. From this perspective, we may define a software process as being a pair process if it is carried out by a team of pairs and as a solo process if it is carried out by a team of individual developers. PP includes not only programming but also design, system analysis, testing and other typical programmer activities. There is a great variety of often opposing views on the value of PP and of research agendas. Some take the view that PP is neither as economical nor as productive as solo programming [2–5]. Others argue that more studies of PP productivity are needed [3, 6–8]. Some explore PP such as side-by-side programming [9–11], whereas others propose more traditional alternatives to PP such as reviews [12, 13] and mutual programming [5, 14]. PP also raises issues of staff appraisal, economics and productivity [6, 15, 16]. Further, the complex interrelationships between programmers involved in PP and programming problems have offered a broad field for critics of empirical studies on PP and invite questions as to how research findings can be applied in the workplace [2]. The claimed benefits of PP are also many and various. Typically offered examples include job rotation/succession against personnel turnover, skills transfer for knowledge management and, as a result of pairs being able to explore a larger number of alternatives than a single person [17], the generation of more and better ways to solve problems. Many empirical studies [6, 15, 18, 19] have shown that PP processes are more ‘productive’ than solo programming process. In summary, it has been generally accepted that PP is most useful for training and for learning complex tasks [20–22]. PP productivity can vary [19, 20]. Some known factors that substantially affect productivity are pair jelling [21], expertise of programmers [19, 23] and rote tasks [21]. Pairs IET Softw., 2008, Vol. 2, No. 4, pp. 379–390 379 doi: 10.1049/iet-sen:20070035 & The Institution of Engineering and Technology 2008 www.ietdl.org