TITLE: An Adventure in Knowing Too Much ... Or Thinking Too Little
AUTHOR: Eugene Wallingford
DATE: January 19, 2012  4:23 PM
DESC: 
-----
BODY:
To be honest, it is a little of both.

I gave the students in my
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2012-01.html#e2012-01-10T16_05_02.htm">
   compilers course</A>
a small homework assignment.  It's a relatively simple
translation problem whose primary goals are to help
students refresh their programming skills in their
language of choice and to think about the issues we
will be studying in depth in coming weeks: scanning,
parsing, validating, and generating.

I sat down the other day to write a solution ... and
promptly made a mess.

In retrospect, my problem was that I was somewhere in
between "do it 'simple'" and "do it 'right'".  Unlike
most of the students in the class, already know a lot
about building compilers.  I could use all that
knowledge and build a multi-stage processor that
converts a string in the source language (a simple
template language) into a string in the target
language (ASCII text).  But writing a scanner, a
parser, a static analyzer, and a text generator seems
like overkill for such a simple problem.  Besides, my
students aren't likely to write such a solution, which
would make my experience less valuable helping them to
solve the problem, and my program less valuable as an
example of a reasonable solution.

So I decided to keep things simple.  Unfortunately,
though, I didn't follow my own agile advice and do
the simplest thing that could possibly work.  As if
with the full-compiler option, I don't really want the
simplest program that could possibly work.  This problem
is simple enough to solve with a single pass algorithm,
processing the input stream at the level of individual
characters.  That approach would work but would obscure
the issues we are exploring in the course in a lot of
low-level code managing states and conditions.  Our goal
for the assignment is understanding, not efficiency or
language hackery.

I was frustrated with myself, so
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2012-01.html#e2012-01-04T15_26_03.htm">
   I walked away</A>.

Later in the day, I was diddling around the house and
occasionally mulling over my situation.  Suddenly I saw
a solution in mind.  It embodied a simple understanding
of my the problem, in the middle ground between too
simple and too complex that was <EM>just right</EM>.

I had written my original code in a test-first way, but
that didn't help me avoid my mess.  I know that pair
programming would have.  My partner would surely have
seen through the complexity I was spewing to the fact
that I was off track and said, "Huh?  Cut that out."
Pair programming is an unsung hero in cases like this.

I wonder if this pitfall is a particular risk for CS
academics.  We teach courses that are full of details,
with the goal of helping students understand the full
depth of a domain.  We often write quick and dirty code
for our own purposes.  These are at opposite ends of
the software development spectrum.  In the end, we have
to help students learn to think somewhere in the middle.
So, we try to show students well-designed solutions that
are simple enough, but no simpler.  That's a much more
challenging task that writing a program at either
extreme.  Not being full-time developers, perhaps our
instincts for finding the happy medium aren't as sharp
as they might be.

As always, though, I had fun writing code.
-----