A methodology for the capture and analysis of hybrid data: a case study of program debugging

No description supplie

XP and pair programming practice

No description supplie

The collaborative nature of pair programming

This paper considers the nature of pair programming. It focuses on using pair programmers’ verbalizations as an indicator of collaboration. A review of the literature considers the benefits and costs of co-operative and collaborative verbalization. We then report on a set of four one-week studies of commercial pair programmers. From recordings of their conversations we analyze which generic sub-tasks were discussed and use the contribution of new information as a means of discerning the extent to which each pair collaborated. We also consider whether a particular role is more likely to contribute to a particular sub-task. We conclude that pair programming is highly collaborative in nature, however the level of collaboration varies according to task. We also find that tasks do not seem aligned to particular roles, rather the driver tends to contribute slightly more across almost all tasks

Pair Programming and the Mysterious Role of the Navigator

Computer programming is generally understood to be highly challenging and since its inception a wide range of approaches, tools and methodologies have been developed to assist in managing its complexity. Relatively recently the potential benefits of collaborative software development have been formalised in the practice of pair programming. Here we attempt to 'unpick' the pair programming process through the analysis of verbalisations from a number of commercial studies. We focus particularly on the roles of the two programmers and what their key characteristics and behaviours might be. In particular, we dispute two existing claims: (i) That the programmer who is not currently typing in code ("the navigator") is constantly reviewing what is typed and highlighting any errors (i.e. acting as a reviewer); (ii) That the navigator focuses on a different level of abstraction as a way of ensuring coverage at all necessary level (i.e. acting as a foreman). We provide an alternative model for these roles ("the tag team") and suggest that a key factor in the success of pair programming may be the associated increase in talk at an intermediate level of abstraction

Factors affecting the perceived effectiveness of pair programming in higher education

Abstract. This paper reports the findings of a study conducted on postgraduate students of an Object Oriented Programming (OOP) course in which pair programming was applied as an educational technique. This study addressed the question Why is pair programming sometimes ineffective? The focus of the study was on exploring the factors that may affect the success of pair programming. We employed a combination of data gathering techniques and triangulated them to analyze the data. We observed, recorded and interviewed students who pair programmed. They also completed questionnaires. There was evidence that matching by skill level and the task in hand are the main factors in the success of a pair programming session. 1