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
<A HREF="http://www.sigcse.org/">
   SIGCSE</A>
mailing list and ran across
<A HREF="http://www.cs.cmu.edu/~pattis/">
   Rich Pattis</A>'s
paper, "A Philosophy and Example of CS-1 Programming
Projects"
<A HREF="http://www.cs.uni.edu/~wallingf/blog-multimedia/p34-pattis.pdf">
   (pdf)</A>,
from the February 1990 issue of the ACM SIGCSE
Bulletin.  Having recently
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-03.html#e2006-03-02T18_36_30.htm">
   written about Rich's work</A>,
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
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-11.html#e2005-11-04T08_34_32.htm">
   Ward Cunningham</A>.
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:
<UL>
<LI> Students "are more motivated and enthusiastic
     about writing programs whose significance and
     usefulness they can plainly understand."

     Long-time Knowing and Doing readers know that
     this topic is
     <A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-03.html#e2005-03-24T11_29_18.htm">
        often on my mind</A>.

<LI> Real problems are complex and may require code
     and ideas that are beyond the students' current
     level of understanding.  But "one way to simplify
     a programming project is to provide students with
     packages that contain useful operations that are
     beyond their ability to write."

     Anyone who has been trying to teach OOP faithfully
     in the first year recognizes this as a central
     theme.
</UL>

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:

<BLOCKQUOTE><EM>
... 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.
</BLOCKQUOTE></EM>

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.
-----