IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, PEER REVIEW DRAFT TSE-2010-07-0237 1 Structural Complexity and Programmer Team Strategy: An Experimental Test Narayan Ramasubbu, Chris F. Kemerer (IEEE Computer Society Member), and Jeff Hong Abstract— This study develops and empirically tests the idea that the impact of structural complexity on perfective maintenance of object-oriented software is significantly determined by the team strategy of programmers (independent or collaborative). We analyzed two key dimensions of software structure, coupling and cohesion, with respect to the maintenance effort and the perceived ease-of-maintenance by pairs of programmers. Hypotheses based on the distributed cognition and task interdependence theoretical frameworks were tested using data collected from a controlled lab experiment employing professional programmers. The results show a significant interaction effect between coupling, cohesion, and programmer team strategy on both maintenance effort and perceived ease-of-maintenance. Highly cohesive and low-coupled programs required lower maintenance effort and were perceived to be easier to maintain than the low cohesive programs and high-coupled programs. Further, our results would predict that managers who allocate maintenance tasks to independent or collaborative programming teams depending on the structural complexity of software could lower their team’s maintenance effort by as much as 70% over managers who use simple uniform resource allocation policies. These results highlight the importance of achieving congruence between team strategies employed by collaborating programmers and the structural complexity of software. Index Terms—Object-Oriented Programming, Complexity Measures, Software Quality, Programming Teams, Maintenance Process, Management —————————— —————————— 1 INTRODUCTION rganizations spend a significant proportion of their While both of these factors (programmer strategy and O IT budgets on software maintenance with aims to software structure) have influence on the final outcome, improve software quality and to prolong system life. the interactions of these two elements have generally been However, a disproportionate allocation of resources to neglected and leaves open the possibility that simply bet- maintenance activities can potentially reduce the ability of ter matches of programmer strategies and situations may firms to innovate through new application development, a result in improved performance outcomes. In addition, phenomenon termed the ―legacy crisis‖ [1]. there has been a consistent and growing emphasis on In response to the challenge of reducing system main- team approaches to software development and mainten- tenance costs a wide range of techniques has been devel- ance in both commercial software development and in oped by the software engineering research community [2- software engineering education [16-23]. Therefore, there is 4]. A fundamental principle often utilized by these tech- a need to study the relationship between systems main- niques is that software maintenance is strongly influenced tenance and system structure in more detail by accommo- by structural complexity, i.e., the manner in which pro- dating the programmer team strategies which influence gram elements are organized within a system [5, 6]. It has the conduct of system maintenance activities in order to been shown that through better design the interconnec- determine if there are complementary team mechanisms tions between the various elements of a system can be for specific software structures. Expanding the unit of simplified to aid maintainability [5, 7-10]. However, a ma- analysis to include both the software structural elements jority of the research investigating the relationship be- and the human factors also presents an opportunity to tween software structure and maintenance has either been bridge the prescriptions offered by both the program conducted (a) pertaining to an individual maintainer’s comprehension and the software complexity research approach to maintenance (e.g., cognition and program streams, and has the opportunity to positively influence comprehension studies [11, 12]), or (b) has addressed the maintenance management practice. The objective of the software structure without detailed attention to pro- study is to take a step forward in this direction by examin- grammers’ strategies (e.g., complexity metrics studies [2, ing the joint impact of object-oriented software structure 13-15]). and programmer team strategies on software mainten- ance. The study also offers a contribution to the growing ———————————————— use of experimental design in empirical software engi- N. Ramasubbu is with the Singapore Management University, Singapore, neering research. 178902. E-mail: nramasub@ smu.edu.sg. Variations in programmer team strategies during C. F. Kemerer is with the Joseph M. Katz Graduate School of Business, software maintenance are typically caused by the different University of Pittsburgh, 276C Mervis Hall, Pittsburgh, PA 15260. E-mail: ckemerer@ katz.pitt.edu. ways in which teams achieve their division of labor. Two J. Hong is with the Singapore Management University, Singapore, 178902 widely used team strategies in software projects are E-mail: [email protected]. independent team programming and collaborative team programming [16-23]. Independent team programming Manuscript received (insert date of submission if desired). xxxx-xxxx/0x/$xx.00 © 200x IEEE 2 IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, PEER REVIEW DRAFT TSE-2010-07-0237 (hereafter simply ―independent programming‖) refers to a the theoretical background on the key constructs of this team strategy where system maintenance tasks are study is presented in section 2. Research hypotheses are divided among programmers who work in parallel on developed in section 3. The empirical research design to separate parts of the system and coordinate their efforts test the hypotheses and the experimental procedures are [16, 23]. On the other hand, collaborative team programming described in section 4. Section 5 presents the analysis of (hereafter simply ―collaborative programming‖) refers to the data and the results of the hypothesis tests. Section 6 a scheme where two or more programmers work together discusses the results and their limitations, and Section 7 on the same piece of software rather than working in concludes the paper by highlighting the contributions of parallel on two different parts of the system [16, 18]. It has this study. been shown in organizational studies that the efforts required to achieve mutual understanding of a problem HEORETICAL ACKGROUND and to coordinate among team members under alternative 2 T B team strategy regimes can be significantly different [25- We used two main theoretical perspectives for 27], and therefore the outcomes for independent versus hypothesis development. We conceptualized the collaborative programming strategies can be expected to properties of software maintenance tasks undertaken by also differ. collaborating programmers using the distributed cognition Past research studies examining programmer team theoretical framework [28]. And we analyzed the impact of strategies (including pair-programming) have not the team strategy employed by the programmers and its explicitly accounted for the possible joint effects of system impacts on maintenance performance using the task 1 complexity and team strategy in their design [16-21, 23] . interdependence theoretical framework [25, 27, 29]. This study investigates maintenance tasks done by pair of programmers and specifically focuses on the differences 2.1 Distributed Cognition Framework between two different team strategies—independent programming and collaborative programming employed Software maintenance is recognized both as a by the pairs of programmers, and how the interaction cognitive activity dependent on an individual between the software structure and the team strategy programmer’s system comprehension, and as a social influences maintenance performance. The central research activity involving frequent interactions between question answered by this study is this: What is the effect programmers working in teams [30, 31]. The distributed of programmer team strategy on software maintenance cognition framework posits the study of such cognitive performance for different levels of structural complexity? phenomena by taking into account the social context in To answer this research question we conducted a which the actors are situated, and treating the actors, their controlled lab experiment with 45 professional interactions with one another, and their environment as a programmer pairs (90 subjects). We found that single distributed cognitive system [28, 32]. programmers’ maintenance effort levels (in person Flor and Hutchins [24] were among the pioneers in minutes) and ease-of-maintenance perceptions for the two the application of the distributed cognition framework to different team strategies were highly contingent upon the the study of software maintenance activities. Rogers and structural complexity levels that they encountered. In the Ellis [33] detailed the theoretical basis of distributed lowest possible structural complexity environment of the cognition for studying collaborative activity. Other experiment, programmers employing the independent researchers have also utilized the distributed cognition programming strategy required 49% less effort than framework to study pair programming teams [34].