TITLE: Using the Writing Metaphor in Both Directions
AUTHOR: Eugene Wallingford
DATE: February 07, 2008 10:17 PM
DESC: 
-----
BODY:
I recently came across a SIGCSE paper from 1991 called
<A HREF="http://portal.acm.org/citation.cfm?id=107040">
   Integrating Writing into Computer Science Courses</A>,
by Linda Hutz Pesante, who at the time was affiliated
with the Software Engineering Institute at Carnegie
Mellon.  This paper describes both content and technique
for teaching writing within a CS program, a topic that
cycles back into the CS education community's radar every
few years.  (CS academics know that it is important even
during trough periods, but their attention is on some
other, also often cyclic, attention-getter.)

What caught my attention about Pesante's paper is that
she tries help software engineers to use their engineering
expertise to the task of writing technical prose.  One
of her other publications, a video, even has the enticing
title,
<A HREF="http://stinet.dtic.mil/oai/oai?verb=getRecord&metadataPrefix=html&identifier=ADM000219">
   Applying Software Engineering Skills to Writing</A>.
I so often think about applying ideas from other disciplines
to programming, the thought of applying ideas from software
development to another discipline sounded like a new twist.

Pesante's advice on how to teach writing reflects common
practice in teaching software development:
<UL>
<LI> <A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2008-02.html#e2008-02-06T14_37_43.htm">
        Motivate students</A>
     so that they know what to expect. 
<LI> Attend to the writing process, as well as the final
     product.
<LI> Use analogies to programming, such as debugging and
     code reviews.
<LI> Have students practice, and give them feedback.
</UL>

Given Pesante's affiliation with the SEI, her suggestions
for what to teach about writing made a bigger impression
on me.  The software engineering community certainly
embraces a broad range of development "methodologies"
and styles but, underlying its acceptance even of
iterative methods, there seems to be a strong emphasis
on planning and "getting things right" the first time.

Her content advice relies on the notion that "writing
and software development have something in common", from
user analysis through the writing itself to evaluation.
As such, a novice writer can probably learn a lot from
how programmers write code.   Programmers like to be
creative and explore when they write, too, but they also
know that thinking about the development process can add
structure to a potentially unbounded activity.  They use
tools to help them manage their growing base of documents
and to track revisions over time.  That part of the
engineer's mindset can come in handy for writers.  For
the programmer who already has that mindset, applying
it to the perhaps scary of writing prose can put the
inexperienced writer at ease.

Pesante enumerates a few other key content points:
<UL>
<LI> Writing takes place
     <A HREF="http://www.cs.uni.edu/~wallingf/blog/archives/monthly/2007-10.html#e2007-10-18T08_40_16.htm">
        in a context</A>. 
<LI> The writing process is neither linear nor algorithmic. 
<LI> The writing process is iterative.
<LI> <EM>Correct</EM> is not the same as <EM>effective</EM>. 
</UL>

The middle two of these especially feel more agile than the
typical software engineering discussion.  I think that the
agile software community's emphasis on short iterations with
frequent releases of working software to the client also
matches quite nicely the last of the bullets.  It's all too
easy to do a good job of analysis and planning, produce a
piece of software that is correct by the standards of the
analysis and plan, and find that it does not meet the user's
needs effectively.  With user feedback every few weeks,
the development team has many more opportunities to ensure
that software stays on a trajectory toward effectiveness.

Most people readily accept the idea that creative writing
is iterative, non-linear, and exploratory.  But I have
heard many technical writers and other writers of
non-creative prose say that their writing also has these
features -- that they often do not know what they had to
say, or what their ultimate product would be, until they
wrote it.  My experience as a writer, however limited,
supports the notion that almost all writing is exploratory,
even when writing something so pedestrian as a help sheet
for students using an IDE or other piece of software.

As a result, I am quite open to the notion that
programming -- what many view as the creating of an
"engineered" artifact -- also iterative, non-linear, and
exploratory.  This is true, I think, not only for what we
actually call "exploratory programming" but also for more
ordinary programming tasks, where both the client and I
think we have a pretty good handle on what the resulting
programming should do and look like.  Often, over the
course of writing an ever-larger program, our individual
and shared understanding of the program evolves.  Certainly
my idea of the internal shape of the program -- the
structure, the components, the code itself -- changes as
the program grows.  So I think that there is a lot to be
learned going both directions in the writing:programming
metaphor.
-----