TITLE: Multiple Iterations and Care for Programs
AUTHOR: Eugene Wallingford
DATE: August 19, 2004  1:50 PM
DESC: how agility can make not thinking ahead okay
-----
BODY:
Fall semester is in the air.  The students are beginning to arrive.
As I prepare for my courses, I've been thinking about some issues
at the intersection of agile development, programming style, thinking
ahead, cognitive styles, and technology.

Many computer science faculty pine for the good old days when students
had to plan their programs with greater care.  To this way of thinking,
when students had to punch programs on cards and submit them for batch
processing at the computer center, they had to <I>really</I> care about
the quality of their code -- think through their approach ahead of time,
write the code out by hand, and carefully desk-check it for correctness
and typos.  Then came the era of interactive computing at the university
-- when I was an undergrad at
<A HREF="http://www.cs.bsu.edu/">Ball State</A>,
this era began with the wide availability of DEC Vax terminals -- and
students no longer had to be careful.  Professors love to tell stories
from those Vax days of receiving student submissions that were Version
132 of the program.  This meant that the student had saved the program
132 times and presumably compiled and run the program that many times
as well, or close to it.  What could be a worse sign of student attention
to planning ahead, to getting their programs right before typing?

I've never held this view in the extreme, but I used to lament the general
phenomenon.  But my view is now mixed, at best, and moving toward
a more agile perspective.  Under what conditions would I <B>want</B>
my students to save, compile, and run a program 142 times?

In agile development, we encourage taking small steps, getting frequent
feedback from the program itself, and letting a program evolve in
response to the requirements we implement.  In test-driven development,
we explicitly call for compiling and running a program even when we
expect a failure -- and then adding functionality to the program to
make the test pass.

If my students program this way, then they will necessarily end up with
many, many saves and compiles.  But that would be a good thing, and at
every step along the way they would have a program that deserves partial
credit for a correct but incomplete solution.

In order for this approach to be desirable, though, students need to
do more than just code, compile, and run.  They will need to add
individual features to their programs in a thoughtful, disciplined way.
They will need to do some testing at each step, to ensure that the new
feature works and that all older features still work.  They will need
to continuously re-work the design of their program -- refactor! -- as
the design of the program evolves.  And all of these take <I>time</I>.
Not the frenzied iterations of a student whose program is due tomorrow
morning, but the intentional iterations of a programmer in control.

To me, this is the biggest difficulty in getting students to program
in an agile style.  Students are so used to procrastinating, to
doing triage on their to-do lists in order to get the most urgent
project done first.  Unfortunately, many also give higher priority
to non-school activities all too often.  I am always on the look-out
for new ways to help students see how important time is in creating
good programs, whether by planning carefully ahead or by going through
many planned iterations.  Please
<A HREF="mailto:wallingf@cs.uni.edu">share any ideas</A>
you have. 

So, many iterations isn't a problem in itself, but rather a style
in which those iterations are the result of the seemingly random
modify-and-compile approach that many students seem to fall into
when a program gets tough.  Part of our job as teachers is helping
students learn discipline in attacking a problem -- more so than
teaching them any particular discipline itself.

Why the mention of cognitive styles above?  A
<A HREF="http://www.collisiondetection.net/mt/archives/000888.html">blog entry</A>
by Clive Stephenson brought this topic to the front of my mind a few
weeks ago, and it wasn't about programming at all, but about writing
more generally:

<BLOCKQUOTE>
... Is there any difference between our cognitive styles when we write
longhand, versus typing on a keyboard? 

<P> Since I type about 70 words per minute, I can type practically as fast
as I can compose sentences in my head.  So does the much-slower pace
of handwriting actually create a different way not just of writing,
but of thinking? Does the buffer buildup between my brain and my arm
affect things? 

<P> What I mean is this:  When I'm typing, because I can generate text
so fast, I'll toss lots of stuff out on the page -- and then quickly
edit or change it.  But when I'm writing by hand, because it's so much
slower I'll try to compose the sentence in my head before trying to
write it.  With a keyboard, I sort of offload some of my mental-sorting
onto the page, where I can look at the words I've written, meditate on
them, and manipulate them. With writing, that manipulation happens before
the output.  Clearly this would lead to some cognitive difference
between the two modes ... but I can't quite figure out what it would be.
</BLOCKQUOTE>

Changes in technology have made it easier for us to get ideas out of our
heads and onto paper, or into a computer file.  That's true of good ideas
and bad, well-formed and inchoate.  For many writers, this is a *good*
thing, because it allows them to get over the fear of writing by getting
something down.  That's one of the things I like about having my students
use more agile techniques to program:  Many students in introductory
courses are intimidated by the problems they face, are afraid of not
being able to get the Right Answer.  But if they approach the problem
with a series of small steps, perhaps each small step will seem
doable.  After a few small steps, they will find themselves well on the
way to creating a complete program.  (This was also one of my early
motivations for structuring my courses around patterns -- reducing
fear.)

Used inappropriately, the technology is simply a way to do a poor job
faster.  For people whose cognitive style is more attuned to up-front
planning, newer technologies can be a trap that draws them away from
the way they work best.

In retrospect, a large number of compiles may be a bad sign, if they
were done for the wrong reason.  Multiple iterations is not the issue;
the process that leads to them is.  With a disciplined approach, 142
compiles is the agile way!
-----