A Distance Learning
Approach to Teaching
eXtreme Programming
Chris Murphy, Dan Phung, Gail Kaiser
Columbia University
Introduction

Many universities offer distance learning
programs for graduate students who are fulltime professionals

CS departments are incorporating agile
processes like eXtreme Programming (XP)
into software engineering courses

This introduces various challenges
Introduction

We present our findings from a three-year
study of such an online software engineering
course

We discuss these findings in terms of the
course’s educational objectives, using our
observations and the students’ assessment
Overview
Background
 Overview of Study
 Observations & Findings
 Analysis & Assessment
 Suggestions
 Conclusion

COMS W4156

Advanced Software Engineering
 Component-based
software engineering
 eXtreme Programming

Main educational objectives
 Allow
students to participate in a project using
eXtreme Programming, and learn the value of its
core practices
 Teach skills in the domain of quality assurance
 Students
work in teams (two pairs) on a
semester-long project using XP
Columbia Video Network (CVN)
Courses available online
 Same lectures as on-campus course

 Not
targeted specifically to off-campus students

Videos may be used for multiple semesters

http://www.cvn.columbia.edu
Overview of Study
Observed approx. 90 students who took the
CVN version of W4156 from 2004-2007
 All students write a subjective assessment of
their experiences both at the midpoint of the
course and upon its completion
 No objective measurements, just subjective
experiences and our observations

Aversion to XP
Many CVN students were professionals who
were used to other SE methodologies
 Some had already had bad experiences


Collective ownership
 “The
other [pair in our team] had no idea how our
code worked or even was organized, because
[we] never bothered to discuss it. This created a
severe challenge when we later needed to do
integration and testing.”
Aversion to XP

Test-driven development
 “[We
had] an incongruent idea of what unit
testing is supposed to accomplish. In my
[opinion], functionality should be driven by unit
tests, which should be developed first. I would
create tests that I felt expressed the intention we
were trying to accomplish with the program,
while [my partner] was creating and modifying
the UI to fit the various requirements. In the end,
I needed to modify the unit tests to fit his
program, which I believe was a backwards way
of building this system.”
Difficulties in Pair Programming

Students needed to pair program, even
though they were not physically co-located

Challenging to break the group of distance
learning students into pairs
done based on skill-level or students’
personal/social preferences
 Ideally
Difficulties in Pair Programming

Technical challenges
Difficulties in Pair Programming

“Pair programming is a very difficult thing to
accomplish in the type of environment set
forth by a remote class made up of
professional students. From my experience,
pair programming is hard to do even in a
work environment with set hours and close
proximity. Even though [my partner] and I are
the closest in proximity of all the groups, we
have had the hardest time using the pair
programming idiom.”
Scheduling Problems

Many students live in metro-NY area, but
some are on West Coast (3 hrs behind)

Most CVN students are professionals who
need to work during the day, leaving only
weekends and evenings

Impossible to have ad hoc “stand-up
meetings”, which are critical to any XP
project
Scheduling Problems

“After the [midterm], the divide in my group grew
even more. [My partner] and I started working much
less closely because of scheduling issues and
finally, I believe, out of frustration.”

“The challenge is amplified by the fact that the
other half of my pair [is] not only in a different
physical location [from] me, but also in a different
time zone. It is very difficult at times for us to find
common blocks of time to work together. I think it
would be easier just to work independently.”
Issues with Code Inspections

Students missed a good learning experience for a
variety of reasons
 failure
to adequately plan for the meeting
 insufficient time allocated for the inspection
 technical and scheduling issues

One problem “was a result of the technical
communication problems we encountered doing a
large conference call. Use of [text-based] chat, as
was necessary to communicate with one of the
team members who was out of the country, slows
down proceedings dramatically.”
Analysis: XP Core Practices

We estimate that at least half of the students
abandoned the pair programming approach
 only
a small number (fewer than 20%) claimed to
have enjoyed pair programming or learned
valuable lessons from it

Many students (over 65%) admitted that, at
some point during the course, they did not
write unit tests first because of time
constraints or because they did not see the
benefits of doing so
Analysis: Developing QA Skills
Students were able to meet educational
objectives of learning about the importance
of unit, integration, and system testing
 Although some teams failed to conduct
thorough testing, the percent of CVN teams
that did so was not much different from the
percent of on-campus teams
 Code inspections presented additional
challenges

Analysis: Other Issues

Videos are not re-recorded each semester,
due to costs and the fact that the course is
not offered on campus every semester

Recordings of class made in Spring 2004
described EJB 2.1, but EJB 3.0 was released
soon after, and old videos were still being
used up until Summer 2007

Led to much difficulty for course managers
Suggestions

Virtual pair programming
 Use
a combination of tools as in [Hanks
ITiCSE’05] and [Zin JISE’06]

Scheduling
 keep
a fixed weekly schedule for pair
programming sessions and team meetings
 important to communicate frequently, even if the
meetings are not ad hoc and are not face-to-face
Suggestions

Creating teams/pairs
 pre-screen
students to ensure that they are
capable of working in distributed teams on a
project with such short time scales
 confidential peer assessments were conducted
to gauge the personal and professional fit of the
pairs
Conclusion
A Distance Learning
Approach to Teaching
eXtreme Programming
Chris Murphy
cmurphy@cs.columbia.edu
Columbia University