| No single practice of XP stands on its own; instead, it must be reinforced by the practices of XP [Beck2000]. For example, designing for the current requirements as simply as possible works only if you are willing to pause to refactor any part of the code as needed. And you can feel comfortable refactoring code only if you collectively own and understand all the code. Pair programming helps promote this collective ownership. In this chapter, we have discussed several ways for academics to embrace the changes espoused by advocates of XP. Currently, our students do not necessarily practice XP when they program outside of the classroom. We have introduced some of the ways in which our students differ from professional programmers currently practicing XP. Instead, we have attempted to design our curricula and methods to help students practice certain aspects of XP automatically and to understand how these practices can improve the way they think about programming and program design by giving them a view of how programs are constructed. Thus, we feel our efforts are certainly in the style of XP even if we are not doing all 12 practices. However, we feel that more growth is still possible by incorporating some additional practices. Here are some that we are beginning to experiment with. We would like to emphasize testing more in our advanced programming courses. Using tools like JUnit (see http://www.junit.org), we would like to automate the testing process so that students test their code each time they compile. If something did not pass a test, we hope they would be motivated to fix it immediately rather than ignoring it. Initially, we feel that we would have to write these tests for them to get them into that habit. All instructors advise their students to design (or plan) before writing their code, and sometimes beginning students even follow that advice (but it is hard to avoid the lure of the computer). We have begun to incorporate the planning game, along with metaphor (or vision), to make this phase of the project more useful, fun, and concrete for the students. Instead of simply asking students to create a UML diagram, we ask them to make stories, or use cases, and create a project Web page that acts as an advertisement of the team's vision of the project. It is especially hard with group projects to make sure that everyone in the group understands the entire project. To promote better understanding of the overall project, we would like to move students around within and without their group. Additionally, this would force groups to take on new members during the project and have some plan and materials to get new members up to speed on the project's design. |
