TITLE: What to Build and How to Build
AUTHOR: Eugene Wallingford
DATE: October 03, 2011  8:11 AM
DESC: 
-----
BODY:
<I><B>Update</B>: This entry originally appeared on September 29.
I bungled my blog directory and lost two posts, and the simplest
way to get the content back on-line is to repost.</I>

I remember back in the late 1990s and early 2000s when patterns
were still a hot topic in the software world, and many pattern
writers trying to make the conceptual move to pattern languages.
It was a fun time to talk about software design.  At some point,
there was a long and illuminating discussion on the patterns
mailing list about whether patterns should describe <EM>what</EM>
to build or <EM>how</EM> to build.
<A HREF="http://www.dreamsongs.com/">
   Richard Gabriel</A>
and Ron Goldman -- creators of the marvelous essay-as-performance-art
<A HREF="http://www.dreamsongs.com/MobSoftware.html">
   Mob Software</A>
-- patiently taught the community that the ultimate goal is
<B>what</B>.  Of course, if we move to a higher level of abstraction,
a <B>what</B>-pattern becomes a <B>how</B>-pattern.  But the most
valuable pattern languages teach us what to build and when, with
some freedom in the how.

This is the real challenge that novice programmers face, in courses
like CS1 or in self-education: figuring out what to build.  It is
easy enough for many students to "get" the syntax of the programming
language they are learning.  Knowing when to use a loop, or a
procedure, or a class -- that's the bigger challenge.

Our CS students are usually in the same situation even later in
their studies.  They are still learning what to build, even as we
teach them new libraries, new languages, and new styles.

I see this a lot when students who are learning to program in a
functional style.  Mentally, many think they are focused on the how
(e.g., <EM>How do I write this in Scheme?</EM>).  But when we probe
deeper, we usually find that they are really struggling with what to
say.  We spend some time talking about the problem, and they begin
to see more clearly what they are trying to accomplish.  Suddenly,
writing the code becomes a lot easier, if not downright easy.

This is one of the things I really respect in the
<A HREF="http://www.htdp.org/">
   How to Design Programs</A>
curriculum.  Its
<A HREF="http://www.cs.rice.edu/~cork/book/node33.html">
   design recipes</A>
give beginning students a detailed, complete, repeatable process
for thinking about problems and what they need to solve a new
problem.  Data, contracts, and examples are essential elements
in understanding what to build.  Template solutions help bridge
the what and the how, but even they are, at the student's current
level of abstraction, more about what than how.

The
<A HREF="http://www.cs.uni.edu/~wallingf/patterns/recursion.html">
   structural recursion patterns</A>
I use in my course are an attempt to help students think about
what to build.  The how usually follows directly from that.  As
students become fluent in their functional programming language,
the how is almost incidental.
-----