Chapter 21. Bringing Extreme Programming to the Classroom

—Owen L. Astrachan, Robert C. Duvall, and Eugene Wallingford

In this chapter, we discuss several features of Extreme Programming (XP) that we have used in developing curricula and courses at Duke University and the University of Northern Iowa. We also discuss those practices of XP that we teach as part of the design and implementation process we want students to practice as they develop programming expertise and experience. In theory the academic study of programming and software development should be able to embrace all of XP. In practice, however, we find the demands of students and professors to be different from professional and industrial software developers, so although we embrace the philosophy and change of XP, we have not (yet) adopted its principles completely.

Introduction

XP [Beck2000] and other light or agile methodologies [Agile2001; Fowler2000A] have gained a significant foothold in industry but have not yet generated the same heat (or light) in academic settings.

Significant interest in pair programming in an academic setting, and a resulting interest in XP, has been fostered by the work of Laurie Williams [Williams2000; Williams+2000]. However, the general tenets of XP are less known, and the engineering background of many academic computer science programs facilitates adoption of process-oriented methodologies such as the Personal Software Process (PSP) even early in the curriculum [Humphrey1997; Hou+1998]. However, we have had preliminary success in adopting and adapting principles of XP (and other agile methodologies) in classroom teaching and in the methods we teach and instill in our students. Although academic requirements, goals, and methods differ from those in industry, we have found that many aspects of XP can be incorporated into the design and implementation of a university-level computer science and programming curriculum.

What's Extreme about XP?

As explained in [Beck2000], XP takes good practices of professional software development to extreme levels. XP introduces a planned and coherent methodology without becoming overly dictatorial or secretarial. The four values of XP are given as communication, simplicity, feedback, and courage.

As we explain in this chapter, these values form the foundation of our approach. Thus, we think we're following the spirit of XP, although we're certainly not following every XP practice (testing, pair programming, planning game, and so on) [Hendrickson2000].

From these core XP values, five principles are given as fundamental to XP. Our approach uses each of these principles: rapid feedback, assume simplicity, incremental change, embracing change, and quality work.

Ten "less central principles" from [Beck2000] are given, of which we concentrate on the following four: teach learning; concrete experiments; open , honest communication; and local adaptation.

For example, as instructors, we often face a tension in developing good (often small) example programs for students. The tension arises because we want to develop simple, focused examples that teach a specific concept, yet we also want to show our students programs that are masterpieces of good design—programs that are fully generic and robust, and exemplify the best practices of object-oriented design and programming.

XP advocates that we design the simplest possible solution that works well for the current set of requirements, not those that we imagine will exist in the future. This helps relieve some of the tension of designing overly generic or optimized programs when creating example code.

Additionally, with this new mind-set , we can now add new features to that example and show students how the code changes. In other words, we can give the students a peek into the process of creating programs. When we call this process refactoring, we can discuss a program's design in more concrete terms [Fowler2000B].

In this chapter, we report on three aspects of XP that we have employed very successfully. We have used XP in our introductory programming courses for majors, in advanced courses on object-oriented software design, and in programming courses for nonmajors. These three aspects are as follows :