Analysis and Design of Distributed Pair Programming System.

Full text

Page 1

Intelligent Information Management, 2010, 2, 487-497
doi:10.4236/iim.2010.28059 Published Online August 2010 (http://www.SciRP.org/journal/iim)
Copyright © 2010 SciRes. IIM
Analysis and Design of Distributed Pair Programming
System*
Wanfeng Dou, Yifeng Wang, Sen Luo
School of Computer Science and Technology, Jiangsu Research Center of Information Security & Confidential
Engineering, Nanjing Normal University, Nanjing, China
E-mail: douwanfeng@njnu.edu.cn
Received June 7, 2010; revised July 10, 2010; accepted August 11, 2010
Abstract

Pair Programming (PP) that has gained extensive focus within pedagogical and industrial environments is a
programming practice in which two programmers use the same computer to work together on analysis, de-
sign, and programming of the same segment of code. Distributed Pair Programming (DPP) system is a pro-
gramming system to aid two programmers, the driver and the navigator, to finish a common task such as
analysis, design and programming on the same software from different locations. This paper first reviews the
existing DPP tools and discusses the interaction and coordination mechanism in DPP process. By means of
activity theory and language-action theory, some basic requirements of the DPP system are presented. Then,
a design framework of such system and functions of each sub-system are deeply analyzed. Finally, a system
prototype is implemented by plug-in style in Microsoft Visual Studio environment.

Keywords: Pair Programming, Distributed Pair Programming, Software Engineering, Extreme Programming
1. Introduction

In recent years, agile software methodologies have at-
tracted increasing interest within pedagogical and indus-
trial environments, with extreme programming being
considered the most important of these agile methodolo-
gies [1]. In the agile manifesto, the authors state twelve
general principles that all highlight the importance of
flexibility and collaboration. One of these techniques,
which are being adopted by software development group,
is known as Pair Programming (PP), in which two de-
velopers work side by side, on the same computer, to
collaboratively produce a design, an algorithm, a code,
etc [2]. Taking these principles would imply a distributed
application of agile methods, such as distributed extreme
programming. Although some tools have been developed
to better support distributed agile software development,
there is still a need for additional research on tools and
processes for distributed extreme programming, espe-
cially for solutions that extend the most obvious solution
of providing a shared code editor. As the trend towards
global software development continues, pair program-
ming in which two developers are required to work in
face-to-face interaction don’t meet the need of global
software development. This needs to create computer
programs through pair programming practice where de-
velopers are located in different workstation but they
collaborate simultaneously to solve the same problem.
This approach is called Distributed Pair Programming
(DPP). This paper focuses on reviewing the existing dis-
tributed pair programming systems, and presents system
design and implementation. This paper has six sections.
After this introduction, Section 2 gives a related work
about DPP tools. Section 3 discusses analysis approach
of DPP based on activity theory and language theory.
The requirements of DPP tool are presented in Section 4.
Section 5 describes the design and implementation of
prototype system. Section 6 draws conclusions.

2. Related Work

2.1. Pair Programming

Extreme programming, also known as XP, includes a set
of principles and practices for the rapid development of
high quality software. XP identifies 12 best practices of
software development and takes them to an extreme. Pair
programming originated in industry as a key component
of the XP development methodology. As the name sug-
gests, pair programming involves two programmers
*This project was financed partly by the eleventh five-years plan from
Jiangsu Education Science in 2009, No: D/2009/01/093.

Page 2

W. F. DOU ET AL.

working at the same computer to create code or analyze
requirements and develop design and etc. This provides a
mechanism for real-time problem solving and real-time
quality control [2]. One programmer acts as the driver,
who actively writes code or design document and has
control of the keyboard and mouse. The other partner
acts as the navigator, who helps plan as well as identify
and prevent any syntactic or strategic deficiencies in code
or design document, thinks of alternatives and asks ques-
tions [3]. The collaborator may exchange roles at any
time during the pair programming session, or not at all.
The concepts underlying pair programming are not
new [4,5], but pair programming has only recently at-
tracted significant attention and interest within the soft-
ware industry and academia. Several previous controlled
experiments have concluded that pair programming has
many benefits over solo programming [6]. Pair progra-
mming has significant improvements in code reviewing
and various others measures of quality of the programs
being developed including lower duration with only mi-
nor additional overhead in terms of a measure of cost or
effort [4-5]. But, with respect to time taken and im-
provement of functional correctness of the software
product compared with Solo programming showed no
positive effects of pair programming [7]. The reasons are
the difference in sample populations (e.g., students or
professionals), study settings (e.g., amount of training in
pair programming), lack of power (e.g., few subjects),
and different ways of treating the development variables
(e.g., how correctness was measured and whether meas-
ures of development times also included rework), and
task complexity (e.g., simple dependent tasks, or com-
plicated projects) [8-9].
Pair programming originated in industry as a key com-
ponent of the extreme programming development meth-
odology. As the name suggests, pair programming in-
volves two programmers working at the same computer
to create code or analyze requirements and develop de-
sign and etc. This provides a mechanism for real-time
problem solving and real-time quality control [2]. One
programmer acts as the driver, who actively writes code
or design document and has control of the keyboard and
mouse. The other partner acts as the navigator, who helps
plan as well as identify and prevent any syntactic or stra-
tegic deficiencies in code or design document, thinks of
alternatives, and asks questions. The collaborator may
exchange roles at any time during the pair programming
session, or not at all. Pair programming has been shown
to be an effective pedagogical approach in teaching
courses such as introductory computer science [10-11].
Undergraduate software engineering [12], and graduate
object-oriented software development [13]. Studies have
shown that pair programming creates an environment
conducive to more advanced, active learning and social
interaction, leading to students being less frustrated,
Copyright © 2010 SciRes. IIM
488
more confident and more interested in IT [14], and also
improve retention of women in computer science [15].
Pair programming encourages students to interact and
cooperate with partners in their classes and laboratories,
or development teams, thereby creating a more collabo-
rative environment in which pairs discuss problems,
brainstorm each other, and share knowledge. Pair pro-
gramming also benefits the teaching staff. A pair of stu-
dents can always analyze and discuss the low-level tech-
nical or procedural questions that typical burden the
teaching staffs in the laboratory, hence there are fewer
questions to be dealt with.
Distributed pair programming is a style of program-
ming in which two programmers who are geographi-
cally-distributed and synchronously collaborating over
the Internet work together on the same software artifact.
Comparing with pair programming, DPP decreases the
scheduling issues that arise for developers trying to
schedule collocated pair programming. Making DPP
technology available to students increases the likelihood
that they will pair program. Trying distributed pair pro-
gramming increases the likelihood that students will pair
program remotely in the future. While DPP has been
shown to be better than distributed non-pair program-
ming, DPP is not perfect. The main reason is to require a
better tool to support the DPP process.

2.2. Tools of Distributed Pair Programming

In pair programming environment, however, obstacles
such as limited facilities, geographic separation, and
scheduling often present challenges to collocated pair
programming. DPP enables students or developers to
collaborate from different locations to work on their pro-
gramming projects remotely. One of the main trends in
software development has been the globalization of the
software industry. Motivating factors behind this trend
include hiring qualified programmers in different cities
and countries for software companies, placing develop-
ment group closer to their client’s location, creating
quickly virtual development groups, and working con-
tinuously on critical projects by working on different
time zones for groups [16].
Researchers have proposed several tools to better sup-
port distributed pair programming [17-22].These existing
tools adopt either an application sharing approach to en-
hance an existing editor suite or provide customized
tools that include various groupware features such shared
awareness [17]. Customized groupware tools do not
support all of the features needed by pair programming
and thus limit partner’s ability to successfully accom-
plish their work. On the other hand, application sharing
solutions lack process support and thus met collaboration
awareness.

Page 3

W. F. DOU ET AL.

2.2.1. Application Sharing Tools
JAZZ system is an example with an application approach
[18]. It is an extension of eclipse that supports the XP
and workflows in asynchronous interaction. JAZZ allows
users to stay aware of co-workers and initiate chat ses-
sions, and be invited to a synchronous pair programming
session using an application sharing system. JAZZ im-
plements a shared editing plug-in that provides a syn-
chronous shared code editor based on operation trans-
formation approach. But this plug-in is not integrated
into the workflow of pair programming, and thus does
not provide awareness and has no explicit switching of
roles.
MILOS is another application sharing system [19]. IT
provides awareness of co-present users and allows users
to initiate pair programming sessions using application
sharing like JAZZ. MILOS makes use of existing IDEs
and integrates single-user development environments
into pair programming settings. But, application sharing
approach does not support flexible pairing such as one-
to-many pairing way, and role switching. TUKAN is a
special purpose groupware for all phrase of the XP proc-
ess [20]. It provides a shared editor for manipulating
code together and users can highlight important code
using a remote selection. Moomba extends the awareness
tools of TUKAN and support Java IDE where the users
can use a shared java editor [21]. However, TUKAN and
Moomba use ENVY environment and are built as a pro-
prietary tool and thereby cannot provide the same do-
main specific tool support as it is present in modern IDEs.
This is one of the reasons why they have not gain high
popularity.
Eclipse is a popular and more open environment that
allows closer coupling of the developing IDEs [4]. Coor-
dination work can be integrated into Eclipse in the inter-
nal browser window or special-purpose planning plug-in.
The Eclipse Communication Framework (ECF) aims at
integration a collaboration infrastructure with the IDE.
Sangam is an Eclipse plug-in for Eclipse users to share
workspace so that developers may work as if they were
using the same computer [22]. Sangam use an event-
driven design for this plug-in. There are three basic com-
ponents in Sangam: event interceptor, message server,
and event reproducer. The responsibility of the event
interceptor is to capture the event when the driver does
something in Eclipse and then send it to the message
server. When the event reproducer receives a message
and interacts with Eclipse to perform the driver’s action.
Saros plug-in supports driver-navigator interaction in
Eclipse in a distributed pair programming session, and
provides awareness on files that are opened at the
driver’s site [4]. Saros includes a shared editor that al-
lows collaborative code creation, and remote selections
that allow the navigator to point at relevant pieces of
code. Xpairtise is an Eclipse plug-in that offers shared
editing, project synchronization, shared program, test
Copyright © 2010 SciRes. IIM
489
execution, user management, built-in chat communica-
tion, and a shared whiteboard [4].
RIPPLE is a plug-in for the popular Eclipse integrated
development environment in which data on collaborative
programming is collected. RIPPLE is designed for use in
educational setting to facilitate various forms of collabo-
rative programming problem solving including distrib-
uted pair programming and distributed one-to-one tutor-
ing [23]. RIPPLE extends the architecture implemented
in Sangam. Compilation and execution of code, as well
as generation of console message, are performed directly
by Eclipse. However, RIPPLE currently only supports
Java programming because the event-driven behavior of
it requires that language-specific messages be transmit-
ted between users. The textual dialogue of RIPPLE is an
instant-message-style chat program that supports en-
forced turn-taking in dialogue.

2.2.2. Customized Tools
COLLECE, developed using Java technology, is a group-
ware system to support synchronous distributed pair pro-
gramming practices. COLLECE provides a set of tools
including editor, session panel, coordination panels, and
structured chat [24]. The editor provides a workspace in
which the driver inserts or modifies the source code of
the program that is being built. The session panel pro-
vides a simple awareness of partner that shows the photo
and name of each pair. The coordination panels include
three coordination tools that allow a collaboration proto-
col to be established: edition coordination panel, compi-
lation coordination panel, and execution coordination
panel. The structured chat is used to express conversa-
tional acts that are usually used during program coding,
compilation and execution.
COPPER is a synchronous source code editor that al-
lows two distributed software engineers to write a pro-
gram using pair programming. Its functions include
communication mechanisms, collaboration awareness,
concurrency control, and a radar view of the documents,
among others. COPPER system is based on the C/S ar-
chitecture. It is composed of three subsystems: collabo-
rative editor, user and document presence, and audio
subsystems. The editor is further decomposed into the
Editor module and the document server. The Editor
module implements a turn-taking synchronous editor and
the document server provides document storage, docu-
ment editing access control, user authentication and per-
missions, and document presence extensions.
However, low display refresh rate can sometimes be
confusing or something significant may be lost in the
remote display. The trace of the mouse pointer is another
problem if both developers use no same resolution for
their monitors. Hence, next-generation tool is still ana-
lyzed and studied in terms of requirements of distributed
pair programming.

Page 4

W. F. DOU ET AL.

3. Analysis and Interaction in DPP System

3.1. Analysis Based on Activity Theory in DPP
System

Activity theory, as a social psychological theory on hu-
man self-regulation, is a well suited epistemological
foundation for design. Activity theory was first used to
design the user interface by Bodker. Later it has been
extended and refined by numerous other authors. In par-
ticular, activity theory is used to understand cooperative
work activities supported by computers [25,26]. Pair
programming is a social activity involved two program-
mers, driver and navigator. This paper use activity theory
as a theoretical basis for understanding the cooperative
work activities in DPP.
Broadly defined, activity theory is a philosophical
framework for studying different forms of human praxis
as development processes, with both individual and so-
cial levels interlinked. Three of the key ideas of activity
theory can be highlighted here: activities as basic unit of
analysis, the historical development of activities and in-
ternal mediation with activities [25]. Activities—an indi-
vidual can participate in several at the same time—have
the following properties: 1) an activity has a material
object; 2) an activity is a collective phenomenon; 3) an
activity has an active subject, who understands the mo-
tive of the activity; 4) an activity exists in a material en-
vironment and transforms it; 5) an activity is a histori-
cally developing phenomenon; 6) contradiction is real-
ized through conscious and purposeful actions by par-
ticipants; 7) the relationships within an activity are cul-
turally mediated.
Y. Engestrom has made an attempt to establish a struc-
tural model of the concept activity and culturally medi-
ated relationships within it (Figure 1). This structure
includes three components, namely subject, object and
community, and forms three relationships: subject-object,
subject-community and object-community.
This activity model contains three mutual relationships
between subject, object and community: the relationship
between subject and object is mediated by tools, that
between subject and community is mediated by rules and
that between object and community is mediated by the
division of labor. Each of the mediating terms is histori-
cally formed and opens to further development. In this
activity model, four subsystems are formed: production
subsystem, communication subsystem, assignment sub-
system and consumption subsystem.
The production subsystem is used by the subject (e.g.,
driver and navigator) to manipulate the object into out-
come (e.g., analysis, design or programming for a code).
In Figure 1, the production subsystem involves three
components: subject, object and tool. In DPP, this sub-
system is a shared editor that can support the synchro-
Copyright © 2010 SciRes. IIM
490
nous editing, role switching, test execution and file shar-
ing, etc.
Communication subsystem, in Figure 1, involves also
three components: subject, community and rule. For in-
stance, In DPP, the driver and navigator use this subsys-
tem to communicate each other so as to solve the prob-
lems met during pair programming. The driver and
navigator as a community should stand by rules. For
example, a partner as a role of driver, another must be a
navigator. They switch role at intervals. The communi-
cation subsystem that includes the relationship and in-
teraction between subject and community should provide
chat session, whiteboard and audio or video communica-
tion. The communication subsystem must be designed
for users to easy discussion on problems and suggestions
on their task and further focus on the shared code.
Assignment subsystem builds the relationship between
object and community through establishment of the divi-
sion of labor, that is to say, it assign activity according to
social rules and expectation. In DPP, the pair with a
driver role is responsible for writing the code using key-
board and mouse, and the other with a navigator role is
responsible for reviewing the code written by the partner
and gives some suggestions. During DPP, they should
switch the role at intervals.
Consumption subsystem describes how subject and
community to cooperate to act on object. Consumption
process stands for the inherent contradictions of activity
system. Although the goal of the production subsystem is
to transform the object into outcome, it also consumes
the energy and resources of subject and community. The
consumption subsystem may plan arrangement and pro-
vide the resources for DPP.
In Figure 1, the emphasis of analysis of activity sys-
tem is production subsystem. The production of object is
leaded by the results or intention of activity system. For
example, the activities of DPP lead to produce the code
with high quality. Production subsystem is usually con-
sidered to be the most important subsystem. Hence, un-
derstanding the production subsystem will be a good
start for design of DPP system.


Subject Object
Community
Tools
Rules
Division of
labour
Outcome
Production
subsystem
Consumption
subsystem
Communi-
cation
subsystem
Assignment
subsystem

Figure 1. Basic structure of an activity.

Page 5

W. F. DOU ET AL.

3.2. Conversation Model of DPP

In a DPP system, two programmers, the driver and the
navigator, work commonly on the same task such as a
code, or a design, or an analysis by network and related
tools. In order to the efficiency of their programming, the
communication of pairs is important to effective coop-
eration for them. When the driver is editing, the naviga-
tor may observe the code or design remotely and at any
moment to give suggestions about it, or think about op-
tional solution or strategy. In other one, the driver may
request acknowledgement of the pair to it during he/she
writes the code. The conversation model is to describe
the communicating process between the driver and the
navigator so that we clarify how to communicate be-
tween them during pair programming. In follow section,
we construct a conversation model of DPP by means of
language-action theory.
In designing a DPP system for practical situations, we
need to consciously focus on the context and application.
The structure of the system determines the possibilities
for action by the people who use it, and it is this action
structure that is ultimately important. Design is onto-
logical. That is what we are participating in the larger
design of the organization and collection of practices in
which it plays a role. In describing or constructing any
system, we are guided by a perspective. This perspective
determines the kinds of questions that will be raised and
the kinds of solution that will be sought. One can con-
sciously apply a perspective as a guide to design. It will
not provide answers to all of the specific design ques-
tions, but serves to generate the question that will de-
mand answers.
The language/action perspective is one of the relevant
theoretical contributions that have appeared within co-
operative work. Cooperative work is coordinated by the
performance of language actions, in which the partner
become mutually convinced to the performance of future
actions and they make declarations creating social struc-
tures in which those acts are gathered and interpreted
[27]. The language/action perspective has had a signifi-
cant role with computer supported cooperative work. The
PP or DPP is a cooperative activity with two actors,
which can be modeled by language/action perspective.
The language/action perspective emphasis pragmatics,
not the form of language, but what people do with it. The
language/action has five fundamental illocutionary points
—things you can do with an utterance [27]: 1) Assertive
that commits the speaker to something being the case –to
the truth of the expressed proposition; and 2) Directive
that attempts to get the header to do something; and 3)
Commission that commits the speaker to future course of
action; and 4) Declaration that brings about the corres-
pondence between the propositional content of the speech
act and reality; and 5) Expressive that expresses a psy-
chological state about a state of affairs.
Copyright © 2010 SciRes. IIM
491
The need of supporting DPP with suitable computer
based tools implies the investigation of the deep aspects
of cooperation and clarification. Cooperation clarifica-
tion, to the extent that is made up of communication and
negotiation, can be fully characterized under the assump-
tion that the DPP can be viewed as a special linguistic
action game between the driver and the navigator, con-
stituted by asset of rules defining the conversations pos-
sible within it. The results of conceptual and experimen-
tal research motive the following answer: the driver and
navigator spend their time taking commitments for future
activities each other, coordinating the programming work,
switching role according to the situation, explaining the
problems they encounter during pair programming, re-
viewing the code. This needs to precisely develop con-
versation between the driver and navigator in order to
take commitments for an effective negotiation and coor-
dination of the activities.
A conversation between the driver and the navigator
during a DPP process is a sequence of related utterances.
The utterance within a conversation can be classified
from the pragmatic point of view in some basic catego-
ries of speech acts on the basis of their illocutionary
point namely, directives (e.g., Request, Acceptance or
Rejecting of a promise), commission (e.g., Promise,
Count-offer, Acceptance or Rejecting of a commitment,
Declaring of commitment fulfillment). Each conversa-
tion involves two actors in the DPP: the driver and the
navigator, and follows the pattern which defines the pos-
sible sequences of speech acts characterizing the specific
type of conversation. In accordance with language/action
theory, there are also three main types of conversation
occurring in any PP. The first is the conversation for ac-
tion, characterized by the definition of a commitment for
doing an action. The driver in the PP can recognize, e.g.,
the conversations opened by a request, where the driver
opening the conversation asks the partner for some ac-
tivities; the conversation by a promise, where the navi-
gator agrees and provides the support for its fulfillment.
The second is the conversation for possibilities, where
the pairs discuss a new possibility for the code, in terms
of requirements, code structure, language and related
knowledge these conversations, when successful and
devoted to topics under the competence of the pair, end
with a declaration explaining the concept and agreeing
with the code. The third is the conversation for clarifica-
tion, where the pairs cope with or anticipate breakdowns
concerning interpretations of conditions of satisfaction
for action. The conditions are always interpreted with
request to an implicit shared background, but sharing is
partial and needs to be negotiated. There is no sharp line
between them, but they are accompanied by different
moods.
The PP is characterized by a specific organizational
rule, which define the roles of pair programming, role
switching and compatibility of pairs. These rules can be