TITLE: Nothing From Scratch
AUTHOR: Eugene Wallingford
DATE: February 22, 2011  4:06 PM
DESC: 
-----
BODY:
Over the weekend, I enjoyed re-reading Brian Foote's
<A HREF="http://www.laputan.org/frameworks/ruminations.html">
   The Craftsmen vs. the Scavengers</A>,
which is subtitled "The Ruminations of a Foot Soldier on
the Reuse Revolution".  Foote expressed an idea that has
been visited and re-visited every so often in recent years:

<BLOCKQUOTE><EM>
In a world dominated by code reuse, <B>all</B> programming,
will, in one sense, be maintenance programming.
</EM></BLOCKQUOTE>

Foote was a student of Ralph Johnson, who has written and
spoken occasionally about the idea that software development
is program transformation.  I
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2006-06.html#e2006-06-18T10_20_18.htm">
   blogged about</A>
Ralph's idea and what it meant for me nearly five years ago,
just before teaching an intro CS course that emphasized the
modification and extension of existing code.

Some people worry that if we don't start students off with
writing their own code from scratch they won't <EM>really</EM>
learn to program.  Most of the students in that CS1 course
have turned out to be pretty good programmers; that's just
anecdote, of course, and not evidence that the approach is
write or wrong.  But at least I don't seem to have done
them irreparable harm.

This idea is comfortable to me as an old Smalltalk programmer.
As Foote elaborates, the Smalltalk toolset supports this
style of programming and, more importantly, the Smalltalk
<EM>culture</EM> encouraged code reuse, sharing, and a
sense of collective code ownership.  We all felt we were
in the same boat -- the same image -- together.

The commingling of Foote's assertion and my recollection
of that CS1 course caused my mind to wander down another
path.  What about those times when we do start with a
blank slate on a new project?  If we approach the task
as programming from scratch, we might well design a
complete solution and try to implement it as a single
piece.  When I do maintenance programming, I don't usually
think that way, even when I have a major change to make
to the program.  I'm usually too scared to change too
many things at once!  Instead, I make a series of small
changes to the code, coaxing and pruning the system
toward the goal state.  This is, I think, just what XP
and TDD encourage us to do even when we code on a blank
slate.  It's an effective way to think about writing new
programs.

The very next section of Foote's paper also caused echoes
in my mind.  It suggest that, in a culture of reuse, bad
design might drive out good design simply by being there
first and attracting an audience.  Good design takes a
while to evolve, and by the time it matures a mediocre
library or framework might already control the niche.
This may have happened in some parts of the Smalltalk
world, but I was lucky not to encounter it very often.
Foote's idea comes across as another form
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2010-11.html#e2010-11-11T08_00_54.htm">
   Gresham's Law for software design</A>,
so long as we are willing to mangle the original sense of
that term.  The effect is similar: the world ends up
trafficking in a substandard currency.

It sobers me to note that Foote wrote this paper in the
summer of 1989.  These ideas aren't new and have been on
the software world's mind since at least the shift to OOP
began twenty-five years ago or so.  There truly is
<A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2011-02.html#e2011-02-19T09_55_21.htm">
   nothing new for me to say</A>.
As a community, though, we revisit these ideas from
different vantage points as we evolve.  Perhaps we can
come away with new understanding as a result.
-----