A framework for understanding the factors influencing pair programming success

Pair programming is one of the more controversial aspects of several Agile system development methods, in particular eXtreme Programming (XP). Various studies have assessed factors that either drive the success or suggest advantages (and disadvantages) of pair programming. In this exploratory study the literature on pair programming is examined and factors distilled. These factors are then compared and contrasted with those discovered in our recent Delphi study of pair programming. Gallis et al. (2003) have proposed an initial framework aimed at providing a comprehensive identification of the major factors impacting team programming situations including pair programming. However, this study demonstrates that the framework should be extended to include an additional category of factors that relate to organizational matters. These factors will be further refined, and used to develop and empirically evaluate a conceptual model of pair programming (success)

Should I Bug You? Identifying Domain Experts in Software Projects Using Code Complexity Metrics

In any sufficiently complex software system there are experts, having a deeper understanding of parts of the system than others. However, it is not always clear who these experts are and which particular parts of the system they can provide help with. We propose a framework to elicit the expertise of developers and recommend experts by analyzing complexity measures over time. Furthermore, teams can detect those parts of the software for which currently no, or only few experts exist and take preventive actions to keep the collective code knowledge and ownership high. We employed the developed approach at a medium-sized company. The results were evaluated with a survey, comparing the perceived and the computed expertise of developers. We show that aggregated code metrics can be used to identify experts for different software components. The identified experts were rated as acceptable candidates by developers in over 90% of all cases

Collaboration in Pair Programming: driving and switching

This paper reports on an empirical study about the mechanisms of the collaboration of drivers and navigators in Pair Programming (PP) sessions. Based on video recordings of professional software developers, we analysed the mechanisms of role switches and how developers split the task of driving. We found that developers do not evenly contribute to the task of driving and that they spend on average a third of the session without any computer interaction focusing mainly on communication. In addition, our results show that most pairs switch roles frequently and that the frequency and fuidity of switches indicate a high level of engagement on the part of both developers

Distributed-Pair Programming can work well and is not just Distributed Pair-Programming

Background: Distributed Pair Programming can be performed via screensharing or via a distributed IDE. The latter offers the freedom of concurrent editing (which may be helpful or damaging) and has even more awareness deficits than screen sharing. Objective: Characterize how competent distributed pair programmers may handle this additional freedom and these additional awareness deficits and characterize the impacts on the pair programming process. Method: A revelatory case study, based on direct observation of a single, highly competent distributed pair of industrial software developers during a 3-day collaboration. We use recordings of these sessions and conceptualize the phenomena seen. Results: 1. Skilled pairs may bridge the awareness deficits without visible obstruction of the overall process. 2. Skilled pairs may use the additional editing freedom in a useful limited fashion, resulting in potentially better fluency of the process than local pair programming. Conclusion: When applied skillfully in an appropriate context, distributed-pair programming can (not will!) work at least as well as local pair programming

Software Architecture Improvement through Test-Driven Development

This research involves empirical software engineering studies applied in academic and professional settings to assess the influence of test-driven development on software quality. Particular focus is given to internal software design quality. Pedagogical implications are also examined. Initial results and the study protocol and plans will be presented

Automated tool to assess pair programming program quality

This paper aims to present an automated tool that has been developed to assess pair programming program quality.The tool known as Java Quality Measurement Tool or JaQMeT is used to assess specifically Java program quality.There are two program quality factors that can be assessed which are correctness and complexity. Pair programming program will be graded using JaQMeT. Then the results will be used to evaluate the effectiveness of pair programming.JaQMeT is only at its initial stage.It is an initial effort to facilitate the lecturers to reduce workload on grading programming assignment and specifically to assess pair programming program quality.Although JaQMeT has its several limitation but it is hoped that JaQMeT can be extended by using web-based technology and capable to check others program quality

Semblant cerca semblant?: la formació de grups de treball en la pràctica de la programació

En una assignatura del grau d'enginyeria d'informàtica, la pràctica de programació ha passat de ser un treball individual a un treball en equip, en principi per parelles. L'alumnat té llibertat total per formar equips amb una intervenció mínima per part del professorat. L'anàlisi de les parelles formades indica que no hi ha una tendència dels alumnes a associar-se amb alumnes de rendiment semblant, potser perquè paràmetres cognitius generals no regeixen la tria de parella acadèmica. In a course of the degree of computer science, the programming project has changed from individual to teamed work, tentatively in couples (pair programming). Students have full freedom to team up with minimum intervention from professors. The analysis of the couples made indicates that students do not tend associate with students with a similar academic performance, maybe because general cognitive parameters do not govern the choice of academic partners.Peer ReviewedPostprint (published version