TITLE: An Instant Recipe for Success -- for Students and Professors?
AUTHOR: Eugene Wallingford
DATE: November 10, 2004 10:46 AM
DESC: Some meandering thoughts about applying an agile idea, short cycles, to the teaching of programming
-----
BODY:
I liked Incipient Thought's
recipe for project success yesterday.
It starts with T. J. Watson's well-known:
If you want to increase your success rate,
double your failure rate.
... to which he adds a second part:
If you want to double your failure rate,
all you have to do is halve your project length.
Then, winking, he points out that the second step may fail,
because shorter projects may actually succeed more often!
I think this is wonderful software development advice.
As a teacher, I have been thinking about how to bring
this idea to my courses and to my students.
I always encourage my students to approach their course
projects in this way: take lots of small steps doing the
simplest thing possible, writing test code to verify
success at each step, and refactoring frequently to
improve their design. By taking small steps, they should
feel confident that whatever they've done so far actually
works. And, when it doesn't, they haven't gone too far
astray, because they only worked on a little bit of
specification. Debugging can often be localized to the
most recently added code.
Breaking a complex but unitary spec ("implement a program
to play MasterMind") down into smaller stories is hard,
especially for freshmen and sophomores. Even my upper
division students sometimes have difficulty breaking
requirements that are smaller but still too big into even
smaller steps.
In recent semesters, I've tried to help by writing my
assignments as a list of small requirements or user stories.
My second-semester students are currently implementing a
simple text-based voice mail system, which I specified
as a sequence of individual requirements. Sometimes, I
even specify that we will grade assignments story-by-story
and stop as soon as the program "fails" a story.
This approach sounds great, but it is out of step with the
student culture these days. Taking small steps, and
especially refactoring, requires having a certain amount
of time to go through the process, with some reflection
at each step. Most students are inclined to start every
project a few days or less before it's due, at which point
they feel a need to "just do it". I've tried to encourage
them not to postpone starting -- don't all professors face
this problem? -- mostly to no avail.
In my Agile Software Development course, we've been doing
2- and 3-week releases, and I think we've had some success
with doing 3 week-long iterations, with full submission of
the project, within each release. Even still, word in the
class is that many folks start each iteration on a day or
two or three before it's due.
Maybe I should take the "recipe for project success"
advice for them... I could assign two half-week assignments
instead of a one-week assignment! Students would have twice
as many opportunities to succeed, or to fail and learn.
One of the downsides of this idea for me is grading. I don't
like to grade and, while am usually (but not always!) timely
in getting assignments back to students, I use enough mental
energy grading for three courses as it is. I could automate
more of the grading, using JUnit, say, to run tests against
the code. But to the extent that I need to look at their code,
this approach requires some new thinking about grading.
One of the downsides of this idea for my students is the
old time issue. With 15 hours of class and 30 hours at work
and whatever time they spend in the rest of their lives,
students have a tough time working steadily on each course
throughout each week. Throw in exams and projects and
presentations during special times in the semester, and the
problem gets worse.
But I can't shake the feeling that there is something deeply
right about halving the size of every project. I may have
to "just do it" myself and face whatever difficulties arise
as they do.
-----