Humanist Discussion Group, Vol. 21, No. 52.
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: Sun, 27 May 2007 08:59:01 +0100
From: "Joris van Zundert" <joris.van.zundert_at_gmail.com>
Subject: Re: 21.046 coding and composing
Dear Wendell, Willard and others,
May I invite all who are even remotely interested in the topic to
click on the link
<http://en.wikipedia.org/wiki/Agile_software_development>Agile
software development at the bottom of
<http://en.wikipedia.org/wiki/Waterfall_model>http://en.wikipedia.org/wiki/Waterfall_model?
Agile software development is what we've been practicing for a while
now at Huygens Institute. It sure has it's own problems, just as any
other software development methodology, but it's the only process
model which I've seen practiced to produce tools that do at least
remotely appeal to what 'customers' in academic environment meant
when stating at the start of a project "I want some tool to do ...".
All other methodologies I've used or was pressed into using only
delivered frustration for both customers and programmers.
My personal theory, although remaining yet to be proven from hard
evidence, is that the relative success we experience when using agile
development is due to it's nature of accepting and trying to
understand change. Ideas change and develop immediately as we try to
put them into practice. 'Stick to the plan' - as waterfall implies -
therefore results in software we wanted when we started the project.
In my experience that's never what the customer wants to have at the
end of the project, because he advanced his thinking during and cause
of the project.
That's why whenever a 'customer' (i.e. a humanist scholar) asks us
for some software functionality, we start out building it according
to what the customer planned for, immediately and in close contact
with that researcher. No detailed technical design upfront, no
implementation decisions (like which database to use) taken
beforehand - just one rule of thumb: implement the simplest thing
that could possibly do the job. Iteration by iteration the code and
functionality than develops on the basis of the researcher's close
involvement and continuous feedback. Eventually we always end up with
something nobody expected and planned for, but something that the
researcher actually can use and does something which is useful to him
or her. Imho there's no upfront specification that can possibly come
near the value that this way of working delivers to the researcher.
Consequently I would (provocatively on purpose) argue that any prior
modelling is merely a waist of intellect. Suggesting that a
predefined model, architecture or design is the best approximation of
things is sheer hubris, as we learn when we put the design into the
practice of coding. Because we then find that the model often needs
to be one hundred percent changed to create a model that better fits
the realities that we experience in real life.
A true agile adept (but I would not want to be such a dogmatic) would
therefore argue that the coding is the modeling, the code is the
design. In that respect agile coding could indeed be described as
"thinking with your hands". Agility hard liners often seem to suggest
that it's either way: design vs agile process. But of course we
should combine the best of breed.
In any case I think agile software development is a strategy that
best fits, mimics and supports the fact that models, ideas and
thoughts develop and evolve. All other strategies implicitly rely on
the assumption that we can know beforehand into every detail what we
are thinking and how we should model that. Especially in academic
environment agile development therefore has a place, because
advancing our thinking and modeling is a purpose of the academic
undertaking. Agile process accepts this changing and evolving of
ideas as a good thing, i.e .as the/a goal of a project, and not as
something that breaks the prime directive of model, design, plan and
planning. As a matter of fact agile process has just one plan: break
the plan. Because we know that what we do model is eventually better
than what we thought out to model. That's not to state that we
shouldn't think before we start, just that we should always test our
thinking by putting our ideas into practice.
y.s.,
Joris
On 5/24/07, Willard McCarty <<mailto:willard.mccarty_at_kcl.ac.uk>
willard.mccarty_at_kcl.ac.uk> wrote:
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:
<mailto:humanist_at_princeton.edu>humanist_at_princeton.edu
Date: Thu, 24 May 2007 07:58:13 +0100
From: Wendell Piez <<mailto:wapiez_at_mulberrytech.com>
wapiez_at_mulberrytech.com>
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/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/Hermeneutic_circle
http://en.wikipedia.org/wiki/Learning_cycle
<http://en.wikipedia.org/wiki/Feedback>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/>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:<mailto:wapiez_at_mulberrytech.com>wapiez_at_mulberrytech.com
Mulberry Technologies,
Inc. <http://www.mulberrytech.com>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/%7Ewmccarty/>http://staff.cch.kcl.ac.uk/~wmccarty/
Received on Sun May 27 2007 - 04:28:28 EDT
This archive was generated by hypermail 2.2.0 : Sun May 27 2007 - 04:28:28 EDT