TITLE: Teaching XP in CS 1 -- Back in 1990! AUTHOR: Eugene Wallingford DATE: April 02, 2006 4:21 PM DESC: ----- BODY: A couple of days ago I was tracking down an article that had been mentioned in a thread on the SIGCSE mailing list and ran across Rich Pattis's paper, "A Philosophy and Example of CS-1 Programming Projects" (pdf), from the February 1990 issue of the ACM SIGCSE Bulletin. Having recently written about Rich's work, I couldn't resist taking it home for a weekend read. Not surprisingly, I am glad I did. On its face, this paper is relatively unassuming. It describes a project that he assigns to his CS 1 students as an example of how he thinks about projects. Reading it reminded me of the sort of simplicity I associate with Ward Cunningham. But I was amazed to see Rich talk about two ideas that have been discussed everywhere in CS education for the last few years. Section 2 is titled "Using Packages in Projects". It lays out Rich's philosophy of projects, which consists of at least two key ideas: Then, Section 5 describes the software "methodology" that Rich taught his students, which he called Stepwise Enhancement. If you read this paper today, you'll say to yourself, wait a minute, that's XP! Consider these fragments:
... students first must reduce the program specifications to a minimum, concentrating on their main structural features and ignoring all the complicated details that will make the program difficult to write. Then they design, implement, and test ... a complete version of the program that meets these simplest specifications. The students continue repeating this process - at each stage enhancing the specifications and writing an enhanced program that meets these new specifications - until they have solved the complete problem described in the original specifications. At every stage they are making small additions or modifications to an already correct (for the simplified specifications) program. Fundamentally the stepwise-enhancement technique is useful because it is easier to design, implement, and test a series of increasingly more sophisticated complete programs than it is to attempt writing one large program that solves the original problem specifications at the outset... This technique also allows students to test their original ideas on how to solve the main features of the problem in a simple program first. They receive feedback, at very short intervals, that tells them whether or not they are on the correct path to a solution program. ... such feedback is critical for students who are learning in parallel the language features and how to use these features when writing programs. As students gain more programming experience, it will become more obvious to them what are the important structural features in specifications and what are the complicated details.... At the end of each stage, students should have a working program that they can test on the computer to ensure that it correctly solves the problem at that stage.... If they do not finish a program, they still should have a running program that solves a simpler problem.
I could quote more, but there is something known as "fair use". Besides, you should just go read the paper, which you can find in the ACM Digital Library. Bonus points to the reader who finds the most XP values and practices in this three quarters of a page of text! Plus, you get a sense of the practical experience Rich had gained while teaching this style of development. I haven't even mentioned the sample project, a simple cardioverter-defibrillator. Now that I am on deck to teach our CS1 course, I have a great place to adapt and use this project when teaching about selection and repetition. After reading this paper, I realize how much fun I will have going back to my old CS1 notes, ten years old and older, and recalling how I was teaching elementary patterns and little bits of agile methods back then. I hope that I do an even better job of teaching CS1 after my experiences from the last decade. Rich wrote this paper almost 17 years ago -- which should remind all of us who are trying to do new things that there isn't much that is all that new. We have a lot to learn from what folks were doing before our new ideas came along. You just have to know where to look. Considering that guys like Rich and the folks he hangs out with are usually thinking about big ideas and how they might help us improve CS education before anyone else, any CS educator would do well to keep an eye on what they were doing a few years ago. And whatever they are doing right now, well, we'll probably all be doing that in a few years. -----