TITLE: Agile as Students, but Not Always as Programmers
AUTHOR: Eugene Wallingford
DATE: December 28, 2005  10:31 PM
DESC: 
-----
BODY:
I've noticed an interesting disconnect between student
behavior when in the role of student and when in the
role of software developer.

When they are in the role of developer, students often
fight the idea of XP's small steps: breaking tasks
into small, estimable steps, writing a test for each
small step, and then making sure the code passes the
test before thinking about the next step.  They want
to think ahead, trust their experience and "intuition",
write a lot of code -- and only then compile, run, and
test the code.  The testing is usually sloppy or, more
charitably, incomplete -- at least in part because they
are champing at the bit to move on to more code.

Is this merely a matter of habit they have developed
in past CS courses?  Or have their years in the K-12
educational system encouraged them to rush headlong
into every problem?  Perhaps it is our natural human
state.

... but when in the role of <EM>student</EM>, students
tend behave much differently.  They want feedback --
now.  When they turn in an assignment, they want the
graded result as soon as possible.

I used to have a serious Grading Avoidance Problem,
and all my students disliked it.  Students who were
otherwise quite happy with my course became cranky
when I fell behind in returning assignments.  Students
who were unhappy with the course for other reasons,
well, they became downright hostile.

I'm mostly over this problem now, though I have to
be alert not to backslide.  Like a recovering addict,
I have to face each day anew with resolve and humility.
But I have a colleague for whom this issue is still a
major problem, and it creates difficulties for him with
his students.

I can't blame students for wanting graded items back
quickly.  Those grades are the most reliable way they
have of knowing where they stand in the course.  Students
can use this feedback to make all sorts of decisions
about how and how much to study.  (I do wish that more
students paid more attention to the substantive feedback
on their assignments and tried to use that information
to improve their technique, to guide decisions about
<EM>what</EM> to study.)

So: students like frequent feedback to guide their
studies.

Many students also seem to prefer small, discrete, and
detailed tasks to work on.  This is especially true of
students who are just learning to program, but I also
see it in juniors or seniors.  Many of these upper-division
students do not seem to have developed confidence in
their ability to solve even medium-sized problems.  But
when they are given a set of steps that has already been
decomposed and ordered, they feel confidence enough to
get the job done.  They are industrious workers.

Confessions of a Community College Dean captured my
feeling about this feature of today's students when
<A HREF="http://suburbdad.blogspot.com/2005/11/teaching-in-context-or-all-hail-dr.html">
   it said</A>,
"As a student, I would have been insulted by this
approach.  But they aren't me."  I myself enjoy
tackling big problems, bringing order to an unruly
mass of competing concerns.  Had I always been
spoon-fed toy problems already broken into nearly
trivial pieces, I wonder if I would have enjoyed
computer science as much.  I suspect I might have
because, like many people who are attracted to CS,
I like to
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-11.html#e2005-11-18T21_37_50.htm">
   create my own problems</A>!

So: students like to work on small, well-developed
tasks whose boundaries they understand well.  This,
too, helps students focus their study.

My net acquaintance Chad Orzel, a physicist at Union
College,
<A HREF="http://www.steelypips.org/principles/2005_11_06_principlearchive.php#113157936902345956">
   speculates on why</A>
students prefer to work in this way.  The conventional
wisdom is that working on many small, discrete tasks
encourages them to keep up with their reading.  But
I think he is right when he takes this diagnosis one
step further:  This style of course helps students
to compensate for poor time management skills.  Larger,
less well-defined units require students to figure
out what the subtasks are, estimate how long each will
take, and then actually do them all in a timely fashion.
By structuring our courses as a set of smaller, discrete
tasks, we do much of the preparatory work for our students.
When students are first learning, this is good, but as
they grow (or should be growing) we are merely reinforcing
bad habits.

It seems that we professors are enablers in a system of
codependency. :-)

Even in this regard, the relationship between student as
software developer and student as student holds.  As I have
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2005-02.html#e2005-02-10T17_02_34.htm">
   written before</A>,
software methodologies are self-help systems.  Perhaps
so are the ways we structure problems and lectures for
our students.

Once again, I can't blame students for preferring to
work on small, discrete, well-defined tasks.  Most
people work better under these circumstances.  Even
those of us who love the challenge of tackling big
problems usually succeed by taming the problem's
complexity, reducing it to a system of smaller,
independent, interacting components.  That's what
design is.

Students need to learn how to design, too.  When
students are getting started, professors need to
scaffold their work by doing much of the design for
them.  Then, as students increase in knowledge and
skill, we need to pull the scaffolding away slowly
and let students do more and more of their own design.
It's easy for professors to fall into the habit of
finely specifying student tasks.  But in doing this
thinking for them, we deny them the essential experience
of decomposing tasks for themselves.

Maybe we can leverage the agile-facing side of student
behavior in helping them to develop agile habits as
software developers.  People aren't always able to
change their behavior in one arena when they come to
see that it is inconsistent with their behavior in
another; we aren't wired that way.  But knowing ourselves
a little better is a good thing, and creates one more
opportunity for our mind to grow.

(I doubt going the other way would work very well.  But
it might take away some of the pressure to grade work
quickly!)
-----