Discontinous use of Pair Programming

Discontinous use of Pair Programming

Barbara Russo (Free University of Bozen-Balzano, Italy), Marco Scotto (Free University of Bozen-Balzano, Italy), Alberto Sillitti (Free University of Bozen-Balzano, Italy) and Giancarlo Succi (Free University of Bozen-Balzano, Italy)
Copyright: © 2010 |Pages: 12
DOI: 10.4018/978-1-59904-681-5.ch014
OnDemand PDF Download:
$30.00
List Price: $37.50

Abstract

Pair Programming (PP) has usually considered non effective for distributed teams, not working most of the time together (Williams et al., 2000; Baheti et al., 2002). In this chapter we discuss the effectiveness of PP at transferring knowledge and skills among students that met only occasionally and worked mostly independently. The effect of geographical distance between pair programmers has been already addressed by Baheti et al. (2002). They performed an experiment on a graduate class to assess whether it is feasible to use distributed PP to develop software. It turned out that distributed (i.e., geographically distant) pair programming teams can effectively develop software, that is, with productivity (in terms of LOC/hr) and code quality (in terms of grade awarded to the project developed) comparable to those of close-knit teams.
Chapter Preview
Top

14.1 Introduction

Pair Programming (PP) has usually considered non effective for distributed teams, not working most of the time together (Williams et al., 2000; Baheti et al., 2002). In this chapter we discuss the effectiveness of PP at transferring knowledge and skills among students that met only occasionally and worked mostly independently.

The effect of geographical distance between pair programmers has been already addressed by Baheti et al. (2002). They performed an experiment on a graduate class to assess whether it is feasible to use distributed PP to develop software. It turned out that distributed (i.e., geographically distant) pair programming teams can effectively develop software, that is, with productivity (in terms of LOC/hr) and code quality (in terms of grade awarded to the project developed) comparable to those of close-knit teams.

Kircher et al. (2001) identify the aspects of XP which require co-located programming teams. The authors analyze these aspects in the distributed development of software for collaborative productivity. They found that the effectiveness warranted by physical proximity could not be completely substituted by any communication tool, though various combinations turned out to be quite effective. However, their findings are based only on the personal opinions of the participants, the authors themselves, and no empirical evidence is provided.

We report on the experience of a group of fifteen students doing a summer internship experience at the end of their first year of a first degree in Applied Computer Science at the Free University of Bolzano (Italy). For three months students worked either in companies or research centers the whole week but Friday afternoons, when they met altogether in a university laboratory. Here, they worked on a different project using PP. Our aim was to monitor the knowledge they acquired from such a structured context. Even if such an environment is not distributed in the genuine sense of the term, similar factors may affect the success of the project. Indeed problems with non-continuous use of the same software practices, difference of environments and requests and geographic distance can be equally experienced.

Top

14.2 Structure Of The Experiment

As mentioned, this research deals with a group of fifteen (volunteer) students doing a three-month summer internship.

Eleven students worked in local companies for all the working days but Friday afternoons, when all of them met in a university laboratory for four hours to share their experience. A group of four students worked for a research center of the Faculty – joining the others on Friday afternoons.

The environment was distributed in the sense that the students had the chance to work together only one afternoon per week, spending the rest of the week working in geographically distant places.

In the Friday afternoon meetings all the students had the possibility to share their knowledge and skills by developing software using PP. This work was completely independent from what they were doing over the rest of the week. In all the companies there were no special indications to use XP practices except for students working for the university lab, where XP was continuously adopted.

Altogether, the use of PP was non-continuous – only on Friday afternoons – and alternated with other coding styles.

At the end of their experience students answered to a questionnaire.

14.2.1 GQM of the Experiment

To properly structure the experiment, we use the well known Goal-Questions-Metrics (GQM) paradigm (Wohlin et al., 2000) according to the guidelines of Succi et al. (2002):Goal:

  • Monitoring skills acquired in using PP in order to investigate:

  • Knowledge transfer

  • Effectiveness of a non continuous PP practice - alternated with a different programming methodology

  • Integration of XP skills learned at the university and practices acquired during an industrial internship

Questions:
  • How much effective is the use of PP in transferring knowledge in a distributed environment?

  • How much effective is PP in a non temporary continuous work alternated with other practices?

  • How much effective is the use of PP in integrating university studies and applicative practices of a company of an industrial environment?

Metrics:

  • Final questionnaire

Complete Chapter List

Search this Book:
Reset