TITLE: Teaching Programming Plans Explicitly
AUTHOR: Eugene Wallingford
DATE: July 27, 2004  1:46 PM
DESC: goals and plans in programming
-----
BODY:
Another article to catch my eye in the latest SIGCSE Bulletin was
"Training Strategic Problem Solvers", by de Raadt, Toleman, and Watson.
This brief paper discusses the gap between problem and solution that
students face when learning to program.  Most programming instruction
relies on students to learn problem-solving strategies <I>implicitly</I>
through repeated practice, much as they would in mathematics.

This approach faces a couple of difficulties.  First, as I discuss
in an
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2004-07.html#e2004-07-12T18_58_55.htm">earlier entry</A>,
CS students don't generally get enough practice for this approach to
be effective.  Second, and more troublesome, is that this search for
strategies occurs in a large state space and thus is prone to dead ends
and failures.  Most students will end up constructing the wrong strategies
or no strategies at all.

The authors report the results of an informal experiment in which they
found that their students, after a semester's worth of programming
instruction, had not mastered several simple plans associated with
writing a loop to average a sequence of numbers -- a basic CS 1 problem.
I've heard many other instructors tell a similar story about the
students at their schools.  I've seen many proposals for new approaches
in CS1 offered to address just this problem.

So, what's the solution?

The authors suggest that <I>explicit</I> instruction about goals and plans
will lead to better problem solvers.  They harken back to Soloway's
ground-breaking working on goals and plans as a source for the material
that we should be teaching instead.

I agree wholeheartedly.
The
<A HREF="http://www.cs.uni.edu/~wallingf/patterns/elementary">elementary
patterns</A>
community has devoted much of its energy to identifying the plans that
novice programmers should learn and the problems that they solve.  By
making explicit the forces that lead to or away from a particular pattern,
we hope that students can better learn to make systematic design decisions
in the face of multiple goals.

Notice the subtle shift in vocabulary.  The pattern-oriented approach
focuses on the thing to built, rather than the plan for building it.
This allows one to recognize that there are often different ways to
build the same structure, depending upon the forces of the problem
at hand.  The plan for building the pattern is also a part of the
pattern description.  Soloway's plans were, by and large, code structures
to be implemented in a program, too.  The name "plan" came be thought
of in the same way as a pattern when one considers it in the sense of
an architectural plan, or blueprint for a structure.

Teaching patterns or plans explicitly isn't easy or a silver bullet,
either.  Mike Clancy discusses some of the key issues in his paper
<A HREF="http://portal.acm.org/citation.cfm?id=299673&dl=ACM&coll=portal">Patterns and Pedagogy</A>.
But I think that it offers the best hope for us to get it right.
I hope that de Raadt, Toleman, and Watson will continue with their
idea -- and then tell us the results off their new teaching approach.
-----