Teaching XP: A Case Study

Teaching XP: A Case Study Dwight Wilson Department of Computer Science The Johns Hopkins University 34 th and Charles St. Baltimore, MD 21218 USA +1 410 467 3722 wilson@cs.jhu.edu ABSTRACT This paper reports on a project-oriented course using XP taught at The Johns Hopkins University during the Spring 2001 Semester. The class developed a Java IDE using XP practices. Keywords Extreme Programming, XP, teaching XP 1 INTRODUCTION During the Spring 2001 Semester, the author taught an undergraduate course at The Johns Hopkins University called Software Development with XP. The focus of the course was to teach XP practices in the context of developing a software package of significant size and complexity. One of the goals was that the software would not just be a class project, but eventually be released to the public under the GNU Public License. This paper is a report on that class along with suggestions for teaching similar classes in the future. 2 COURSE DESCRIPTION The course was offered to upper-level undergraduates, with enrollment limited of twenty students and instructor permission required for registration. The required texts for the course were XP Installed [1] and Refactoring [2], with other texts from the XP Series recommended [3,4]. Additionally, several articles from the xprogramming.com web site were used as course readings [5]. The complete list of readings may be viewed on the course website [6]. Learning XP, and software development in general, is not done merely by listening to lectures, but by putting the principles into practice. Thus, the focus of the course was the development of reasonably large piece of software, developed by the class as a whole. An alternative to having the entire class work on a single project would have been to split the class into smaller project groups. This approach was rejected for two main reasons. The instructor played the role of the customer, and time constraints would have made it difficult to play this role for several project groups. The other reason is that using a single project would give students experience working with larger software than if there were multiple projects. 3 THE PROJECT Several factors went into the choice of the programming project. First, as we lacked a "real" customer, it was important that the students be familiar with the problem domain. This would enable students to contribute user stories and write acceptance tests, with the instructor both writing and prioritizing stories. Second, the project should be something of significant size and complexity, yet still allow significant progress to be made during the semester. It would also be useful if future classes could continue development on the same project, again giving a greater real-world feel to the class. It was also considered desirable that the software be usable in the real world, not merely a toy discarded at the end of the semester. Indeed, the intent was to release the software to the public. Since twenty programmers is somewhat large for an XP group, it would be helpful if he project could be easily decomposed into related but somewhat independent subprojects. This would simplify communication between the students, while still allowing them to practice collective code ownership. Finally, the project should be one that would capture the students' interest. The participants shouldn t just be putting in time to get course credit, but should be excited about the project and about XP. The project chosen was to develop a Java Integrated Development Environment (IDE) modeled on Smalltalk IDEs and with support for XP practices. As the class consisted of upper-level Computer Science majors, they were familiar with IDEs, though most were not familiar with Smalltalk IDEs, and could thus contribute user stories. A Java IDE lends itself readily to decomposition into subprojects. Four such subprojects were identified for this semester, core IDE functionality, i.e., editing and navigation, a built-in compiler, CVS integration, and

refactoring support. Each of these would be a challenging semester project for a group of undergraduates, and it was not expected that a complete product would be created. Instead, the goal was develop incrementally and make progress in all subprojects, with future classes continuing the work. This serves to emphasize the XP principles of incremental development and delivering business value in each release. The choice of a Java IDE is also well suited for the creation of additional subprojects in the future, for example a debugger, profiler, etc. In addition to meeting the above criteria, another advantage of this project is that creating features to support XP practices would encourage deeper thought about the practices themselves. The software can also serve as a platform for experimenting with the practices. It should be noted that another factor influenced this choice of project. Some time ago, the author had written a very basic proof-of-concept implementation, i.e., a basic Java IDE modeled on Smalltalk IDEs. The name of this program was Immerjion, motivated by a vague concept of helping programmers immerse themselves in the code. This prototype was used as a starting point for the students. Note that this software was not developed using XP practices. Most importantly there was not an automated unit-test suite. Some thought was given to having the class start from scratch rather than use the prototype, however there were two compelling reasons for using the prototype. First, programmers who use XP in industry frequently have to work with code that was not developed using XP. Using the prototype would give the students experience doing so. In particular, they would benefit by learning to write unit-tests for existing code. Not only is this useful in and of itself, but it helped the students appreciate the benefits of building unit tests from the start and test-first programming. The other reason was that based on concerns about the work environment. A professional programming team practicing XP would normally be in the same work area for most of the week. In contrast, the entire class would only be together for two or three hours a week. Starting with the existing prototype helped provide a single vision of the software that would otherwise have been difficult or impossible to achieve otherwise. 4 THE ENVIRONMENT It is important to understand that there are several environmental differences between an industry team using XP and using it for a University course. One of the most significant, mentioned in the previous section, is that much less time is spent together as a group. Indeed there was not adequate time to discuss users stories, particularly during the first part of the semester when most of the class time was used presenting and discussing the XP practices. This problem was partially solved by creating a user-story Wiki [6]. The Wiki allowed students to enter stories, edit existing stories, make comments, sign up for stories, and mark stories as completed. Another important environmental difference is the amount of time students could spend working. A maximum of eight to ten hours a week outside of class is the most that could reasonably be expected. Scheduling conflicts between students also reduce the amount of time that can be spent pair-programming and meeting with other students. The major adaptation to the time restrictions was to use very small user stories. The use of very small stories in industry teams is mentioned in [1]. The time constraints also influenced some of the project development rules, specifically when pair programming was required and when work could be done as individuals. Essentially, code implementing user stories was required to be written in pairs, however unit-tests for existing code could be written as individuals. Individuals were also permitted to refactor code covered by unit tests. If refactoring was required for code not covered by unit-tests, perhaps in order to simplify writing the tests, pairing was required. A related environmental difference is the lack of a dedicated work area for the project. Students were encouraged to do their project work in the Computer Science Undergraduate Lab, and to try and arrange their schedules so that more than one pair would be working at the same time. While this happened to some extent, the amount of time students spent working at the same time was still quite small. 5 THE PRACTICES While the all twelve XP practices were discussed during lectures, some were emphasized more heavily than the others in practice. The Planning Game An overall plan and release schedule was not created. The major obstacle to doing this was the lack of time available as a group. This was exacerbated by the fact that such planning would have to take place at the start of the semester, when lecture time is needed for presentation and discussion of XP. It must also be admitted that the lack of commercial incentive, i.e., there was no market requirement to have a product out by a target date, reduced the motivation to create an overall plan. Planning for each iteration did follow XP practices. The instructor, acting as the customer, selected which stories were of the highest priority. Students estimated the story size and signed up for stories. Small Releases In order to fit several releases into the semester, two-week releases were used. Strict adherence to this release schedule

was not maintained, particularly at the start of the semester and around midterms. The former was because most of the students had underestimated the time it would take to become familiar with the existing code and thus weren t able to make as much progress on user stories as they had anticipated. It must be made clear, however, that letting the deadline for releases slip was entirely the responsibility of the instructor, not the students. Metaphor The group did not use a metaphor. Starting from a supplied prototype implementation provided conceptual integrity. Simple Design This feature of XP was heavily emphasized during lectures. Overall compliance was good; in general the students avoided building for the future. Testing This practice was the one most strongly emphasized during lectures and in development, if for no other reason that it is valuable even in a non-xp environment. All new code was required to be written in a test-first fashion. Additionally, before changing existing code, creation of tests for that code was required. All unit tests were required to pass before checking in code. Compliance to this practice was very good. There were no unit-test for the initial code, and over 150 tests at the end of the semester. On two or three occasions code was checked in that did not pass unit tests, however this appeared to be more of a problem with the check-in process. For example, on at least one of the occasions, the problem was that a new file had not been added to the repository. This caused the tests to pass on the student s machine, but to fail for the next pair checking out the code. While some students initially described writing unit-tests as a hassle, they quickly came to appreciate the test suite. The class also grew to enjoy test-first programming in conjunction with keeping the design simple. One student remarked that she felt test-first programming encouraged her to do just enough design. That is, enough to meet the needs of the test, which avoiding planning for the future. Adherence to writing acceptance tests was not as great, though some of the unit-tests could be considered to be acceptance tests. The biggest obstacle to acceptance tests is that the software is highly interactive. Automated acceptance tests would require a tool for writing tests using the GUI, and the class did not have such a tool available. It is interesting to compare the reaction of this class with the reaction to unit testing in another course. During the same semester the author also taught Intermediate Programming in Java, a second-semester programming course. One of the assignment requirements was that unit tests, using JUnit, be submitted with each assignment. There was much less enthusiasm about unit-tests in this class than in the XP class. Part of this reason may have been that some students had problems with the mechanics of installing and using JUnit. This was especially true of students coming from an introductory C/C++ class rather than a Java class. Other possible reasons were that individual assignments were not complex enough for the benefits of unit-tests to be appreciated. Overall, most of the students in the Java class perceived the unit-tests as more work that had to be done rather than as a technique for aiding development and improving code. The reverse was true in the XP class. Refactoring The topic of refactoring was covered informally during lectures, with a few examples given. Students were expected to read and apply the refactorings in [2]. Additionally, several of the user stories involved implementing a refactoring tool as part of the IDE. Pair Programming This was another heavily emphasized practice. All new code was required to be written in pairs, the pair writing both the tests and production code. Due to time and scheduling constraints individuals were permitted to write unit-tests for existing code and perform relatively simple refactorings on code covered by tests Pairs were not officially fixed, and students were encouraged to pair with different individuals. In practice many of the students formed semi-permanent pairs. The author also paired with most of the students. A goal was to pair with each of the students, but it wasn t possible to do so because of scheduling difficulties. The students reacted very positively to pair programming. Several of them had worked in pairs on other class projects, but this was the first time it was presented as part of a software development methodology. Collective Ownership Although the development was divided into sub-projects, collective ownership was applied to the entire code base not just within subprojects. Furthermore, membership in a sub-project group was not strict. That is, students were permitted to sign up for any stories at all, not just ones specified as part of their sub-project. Additionally, pairing between programmers in different sub-projects was encouraged to help distribute knowledge. Reaction to this practice was positive, though it must be noted that most students have not had exposure to more restrictive code-ownership practices. Continuous Integration Interestingly, the factors that differentiate the student XP team environment from an industrial one tend to promote the practice of continuous integration. Students generally worked shorter blocks of time, with longer intervals

between blocks, than professional programmers, resulting in greater incentive to check code in more frequently. 40-hour Week As noted earlier, a major difference between a student XP group and an industry group is the time available for work on the project. As a result, in the class, this became the 10- hour week practice. On-site Customer It was not possible to follow this practice, as there was no real customer. Even had there been one, the aforementioned problems of student scheduling would have made an on-site customer impractical. The students were encouraged to act as customers for the purpose of writing user stories, though a little over one-half of the stories were in fact written by the instructor. Since the students were familiar with the problem domain, the lack of an on-site customer did not cause too many problems. On a few occasions a story implemented by a students did not perform as the instructor expected, and the problems would probably have been caught more quickly with an on-site customer. Coding Standard Since development was based on an existing prototype, the class was told to follow the coding standards in that code, rather than coming up with a new standard. Somewhat surprisingly, this was the practice for which there were the most compliance problems. Although the importance of consistency of coding practices was emphasized during class, several students insisted on following their own preferences for brace placement, indentation, white space, etc. It is possible that compliance would have been better had the group created a coding standard rather than had one imposed on them by the existing code. The choice of project, i.e., a Java IDE, may have also contributed to the problem. In the system, code is stored as parse trees, and pretty-printed to editing windows on the fly. This may have created the impression that adherence to formatting standards was not particularly important When the IDE was sufficiently advanced to be used for its own development, pairs could use their own preferences for formatting without affecting the stored form of the code 6 THE RESULT By the end of the semester, the class had created a usable Java IDE, though by no means a complete one. A copy of the source code may be obtained from the course web page [6]. Adherence to XP practices was generally quite good, particularly with regards to pair-programming, unit-testing, and continuous integration. Even though the IDE is not complete, it does deliver business value. The core IDE provides support for navigating Java code, including commands to find all calls of a method, all implementers of a method, etc. The editing interface is somewhat primitive compared to other editors and IDEs, however the primary goal was to support the many small methods style of programming, and is based on editing one method at a time, so sophisticated editing support was not considered a priority. The compiler sub-project is far from complete, but the work done delivers significant business value. The students working on that sub-project implemented user stories describing semantic checks to be performed when a method is saved. This enables errors, such as referencing an undefined identifier, to be caught more quickly. A future class will complete the semantic checks and start implementing code generation. The IDE supports the most common CVS commands, and also supports features to automatically run all unit-tests before a check-in, aborting the check-in should any tests fail. The sub-project with the least project is the refactoring support, simply because those stories were the hardest to implement. At the moment few refactorings are supported, though more will be added by future classes. 7 FUTURE DIRECTIONS The author intends to teach this course in future semesters. Ideally, this course would be taught each semester, with the possibility of interested students participating more than once. The area in which the most improvement can be made is probably adherence to a strict release schedule. As mentioned in the previous section, the end-of-release dates were sometimes allowed to slip so that students could finish their stories. It would be better, both from and educational standpoint and for proper practice of XP, to avoid this. Use of the once-and-only-once rule [7] may be used as well. This rule states that if a pair is unable to complete a story they ve signed up for, then they are not permitted to sign up for that story on the next iteration. Another area of improvement is contact with the students, particularly getting updates on progress. While progress updates were done during class, students appeared somewhat reluctant to admit that they might not finish stories they were working on. A solution being considered is to have each sub-project group to select a representative who would keep in close contact with the group members and report to the instructor. Future classes will maintain and enhance the existing functionality as well as create new areas of major functionality, such as a debugger, profiler, GUI builder, etc. This will provide both experience in working with existing code as well as writing new code. During this semester, more time than originally anticipated was spent learning the existing code and writing unit-tests for it. The test-suite built this semester will help future students master the code

more quickly. The software may also be used in the future as a test bed for additional features that support and perhaps modify XP practices. For example, user stories have been submitted, but not yet implemented, to support very frequent integration. Essentially, these stories describe a feature for the system to automatically check-in code whenever all unit tests are successfully run. The system would also watch for check-ins from other pairs and update its copy of any code that has not been edited. If the code has been edited, the programmer would be alerted that another pair has updated the code being edited. It is difficult to tell whether such frequent integration would be beneficial or not. Implementing it would allow it teams to experiment. 8 CONCLUSION Overall the course was successful. The students built a significant piece of software. While the sub-projects are not complete, a usable system was built and can be further developed by future classes. Additionally, the course was an enjoyable experience, both for the instructor and for the students. A few students remarked that not only had they learned a great deal, but it was also one of the most fun courses they had. One of the students, a graduating senior, said that an interviewer was surprised and impressed that a course on XP was offered. REFERENCES 1. Jeffries, Ron, Anderson, Ann, Hendrickson, Chet.. 2000. Extreme Programming Installed. Addison- Wesley 2. Fowler, Martin. 1999. Refactoring. Addison-Wesley 3. Beck, Kent. 1999. Extreme Programming Explained: Embrace Change. Addison-Wesley 4. Planning Extreme Programming. 2000. Planning Extreme Programming. Addison-Wesley 5. Extreme programming website at http://www.xprogramming.com 6. XP Course website at http://www.dswilson.com/spring2001/xp/index.html 7. Extreme Programming Roadmap at http://www.c2.com