21.046 coding and composing

                Humanist Discussion Group, Vol. 21, No. 46.
       Centre for Computing in the Humanities, King's College London
  www.kcl.ac.uk/schools/humanities/cch/research/publications/humanist.html
                        www.princeton.edu/humanist/
                     Submit to: humanist_at_princeton.edu

         Date: Thu, 24 May 2007 07:58:13 +0100
         From: Wendell Piez <wapiez_at_mulberrytech.com>
         Subject: Re: 21.030 coding and composing?

Dear Willard,

Desmond Schmidt's distinction between the correctness of the program
and the correctness of the model does get close to the heart of the
issues you raise, inasmuch as a program can be wildly wrong, even
when "correct", when the model on which it is based is inadequate.
Writing programs in the classical form you were taught in -- which
we've learned to call the "waterfall model", suggesting everything
just moves along sedately until the moment of implementation, when it
all crashes in at once (but see the link cited below), did seem like
the way to do it in an age where intellectual labor was cheap
relative to computers and the time and expertise required to code
them. Such operations did not (or at least so they thought) have the
luxury of getting it wrong a few times before they got it right.
Perhaps they assumed the difference between "wrong" and "right" to be
clearer than it often is; perhaps they simply assumed that the
modeling problem was relatively straightforward and easy -- as any
committee of intelligent and informed people could do it -- whereas
the implementation in code was hard, required special expertise, and
could only be done by a select few with expensive educations. And
perhaps the sorts of problems they were trying to solve -- mapping
trajectories or calculating payments due -- were easier to model than
the problems we think about ("finding information"). Whatever the
reasons, we now discover the reverse to be more often the case: it's
the specification of what should happen that's the difficult part,
not the making it happen once it's been specified.

Yet while the problems have become harder, the means available for
solving them have become more powerful. So we discover that with
cheap machines, open-source platforms, web-based and self-directed
learning, computer programming does, at length, become more like
composition, in the sense that both become means whereby we can think
with our hands. Just as the writer learns what she thinks by writing
it (and striking it out and rewriting it), the programmer can come to
better understandings of a problem by using the computer as a more
plastic instrument, trying things out -- both in models and in
implementation -- and then scrapping, recasting, refactoring.
Accordingly, both design and implementation can become more
iterative, evolutionary, "spiral", as it's called. This does not
actually bring an end to the old way of doing it, any more than a
writer necessarily spends less time in sentence composition than she
did as a three-year-old child, when sentences were new. It's just
that the waterfall has now become a cascading rapid, development
pouring down through eddies and rivulets, sometimes gathering in calmer pools.

Dare I cite Wikipedia, whose development has also followed a spiral,
and entails both software development and natural language composition?

http://en.wikipedia.org/wiki/Waterfall_model

http://en.wikipedia.org/wiki/Spiral_model

and add to these --

http://en.wikipedia.org/wiki/Hermeneutic_circle

http://en.wikipedia.org/wiki/Learning_cycle

http://en.wikipedia.org/wiki/Feedback

To Nat Bobbit's citation of the "extreme programming" keyword we
should also add "agile programming".

Best regards,
Wendell

At 01:42 AM 5/18/2007, you wrote:
>An interesting article, "Code and Composition", zipped by on Humanist
>a few days ago in an announcement of the latest Ubiquity
>(http://www.acm.org/ubiquity/) -- an online magazine that sometimes
>publishes little gems. In this article Luke Fernandez compares the
>two modes of expression and finds them convergent: writing, not
>entirely spontaneous, involves planning and research; coding, not
>entirely planned, involves discovery during the act of composition.
>In this attempt at a parallel, the first seems obvious, if a bit
>overstated, but the second seems to contradict official stories of
>how writing code should proceed. What is the experience of people
>here? I understand that nowadays no one or few preaches the doctrine
>that a complete specification must be devised beforehand (as I was
>told when I learned many years ago). I think the need to come up with
>a complete flowchart is what put me off programming eventually, along
>with the dreaded "turn-around time" of 2 hrs minimum. In any case, it
>would be interesting to know how exploratory programming is known to
>be these days.

======================================================================
Wendell Piez mailto:wapiez_at_mulberrytech.com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
    Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================

Dr Willard McCarty | Reader in Humanities Computing | Centre for
Computing in the Humanities | King's College London |
http://staff.cch.kcl.ac.uk/~wmccarty/.
Received on Thu May 24 2007 - 03:31:20 EDT