TITLE: It Seemed Like a Good Idea at the Time
AUTHOR: Eugene Wallingford
DATE: March 29, 2007  4:20 PM
DESC: 
-----
BODY:
At SIGCSE a couple of weeks ago, I attended an interesting pair
of complementary panel sessions.  I wrote about one,
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-03.html#e2007-03-08T16_36_00.htm">
   Ten Things I Wish They Would Have Told Me...</A>,
in near-real time.  Its complement was a panel called "It Seemed
Like a Good Idea at the Time".  Here, courageous instructors
got up in front of a large room full of their peers to do what
for many is unthinkable: tell everyone about an idea they had
that failed in practice.  When the currency of your profession
is creating good ideas, telling everyone about one of your bad
ideas is unusual.  Telling everyone that you implemented your
bad idea and watched it explode, well, that's where the courage
comes in.

My favorite story from the panel was from the poor guy who turned
his students loose writing Java mail agents -- on his small college's
production network.  He even showed a short video of one of the
college's IT guys describing the effects of the experiment, in
a perfect deadpan.  Hilarious.

We all like good examples that we can imitate.  That's why we are
all drawn to panels such as "Ten Things..." -- for material to
steal.  But other than the macabre humor we see in watching
someone else's train wreck, what's the value in a panel full of
bad examples?

The most immediate answer is that we may have had the same idea,
and we can learn from someone else's bad example.  We may decide
to pitch the idea entirely, or to tweak our idea based on the bad
results of our panelist.  This is useful, but the space of ideas
-- good and bad -- is large.  There are lots of ways to tweak a
bad idea, and not all of them result in a good idea.  And knowing
that an idea is bad leaves us with the real question unanswered:
Just what should we <EM>do</EM>?

(The risk that the cocky among us face is the attitude that says,
"Well, <STRONG>I</STRONG> can make that work.  Just watch."
This is the source of great material for the next "It Seemed
Like a Good Idea at the Time" panel!)

All this said, I think that failed attempts are invaluable -- if
we examine them in the right way.  Someone at SIGCSE pointed out
that negative examples help us to create a framework in which to
validate hypotheses.  This is how science works from failed experiments.
This idea isn't news to those of us who like to traffic in patterns.
Bad attempts put us on the road to a pattern.  We discover the
pattern by using the negative example to identify the <EM>context</EM>
our problem lies and the <EM>forces</EM> that drive a solution.
Sometimes a bad idea really was a good idea -- had it only been
applied in the proper context, where the forces at play would have
resolved themselves differently.  We usually only see these patterns
after looking at many, many examples, both good and bad, and
figuring what makes them tick.

A lot of CS instruction aims to expose students to lots of examples,
in class and in programming assignments.  Too often, though, we
leave the student discover context and forces on their own, or
to learn them implicitly.  This is one of the motivations of my
work on elementary patterns, to help guide students in the process
of finding patterns in their and other people's experiences.
-----