TITLE: Bowling for CS II
AUTHOR: Eugene Wallingford
DATE: January 14, 2005  4:07 PM
DESC: I bit the bullet and went Full Agile in Day 1 of my first-year programming class.  So far, so good.
-----
BODY:
I took a leap of faith this week.

I teach our second course, CS II.  It comes between an
intro course in which students learn a little bit about
Java and a little bit about objects, and a traditional
data structures course using Ada95.  The purpose of CS
II is to give students a deeper grounding in Java and
object-oriented programming.

The first thing I did on our first day of class was to
write code.  The first line of code I wrote was a test.
The next thing I did was try to compile it, which failed,
so I wrote the code to make it compile.  Then I ran the
test in
<A HREF="http://www.junit,org/">
   JUnit</A>
and watched it fail.  Then we wrote the code to make
it pass.

And then we did it again, and again, and again.

I've long emphasized various agile practices in my
courses, even as early as CS II, especially short
iterations and refactoring.  In recent semesters I've
encouraged it more and more.  Soon after fall semester
ended, I decided to cross the rubicon, so to speak.
Let tests drive all of our code.  Let students feel
agile development from all class and lab work.

Day 1 went well.  We "gang-programmed", with students
helping me to order requirements, write tests, find
typos, and think through application logic.  The
students responded well to the unexpected overhead of
JUnit.  Coming out of the first course, they aren't
used to non-<TT>java.*</TT> or extra "stuff".

In our second session, a lab class, students installed
JUnit in their own accounts and wrote their first
Java code of the semester: a JUnit test against the
app we built in Day 1.

Oh, the app?  Ron Jeffries'
<A HREF="http://www.xprogramming.com/xpmag/BowlingForSmalltalk.htm">
   BowlingGame</A>
etude.  It had just enough complexity to challenge students
but not enough to pull too much of their attention away
from the strange and wonderful new way we were building
the program.

Next time, we'll add a couple of requirements that lead us
to factor out a <TT>Frame</TT>, allowing us to see refactoring
and how tests support changing their code.

I'm excited even as I'm a little on edge.  New things in
the classroom do that to  me.
-----