On May 1, 9:36 am, Gosi <gos...@[EMAIL PROTECTED]
> wrote:
> Notice that scrum does not care what programming languages are used.
> It controls how the pigs and chicken interact.
This is a profound and important point.
The prevailing assumption is that program source is read only by
coders and compilers. It plays no part in the interaction between
developers and users. So Scrum, like other forms of Agile, is formally
insensitive to differences between programming languages.
It is often worth consulting an outsider for a fresh perspective. I
described my professional work to my former philosophy tutor. She said
it sounded like an exercise in collaborative reasoning.
This makes some sense. (Not everything you get from philosophers seems
to.) Software is the executable description of the behaviour of a
machine; 'executable' meaning written so a computer can behave the
same way. The machine might be real (eg a DVD player) or imaginary.
(It must be a long time since Microsoft Word reminded anyone of a
typewriter.) So members of a software project collaborate on a written
description of some behaviour.
Consider two other common forms of collaborative writing: drafting
legislation and developing screenplays. Like software projects, both
produce texts that are 'executed' in specific contexts: legislation in
courtrooms, screenplays during principal photography. Like software
projects, both typically have expert writers serving the needs of a
larger number of interested parties who must approve the work.
With the handling of texts, a sharp difference emerges. Legislation is
drafted by a few expert writers, and read and discussed by
politicians, civil servants, lawyers and civic groups, who propose
changes. A movie screenplay is drafted by one or a few writers, and
reviewed by producers, actors, directors and bankers, who propose
changes. In both cases, a few writers and a wider circle of critics
collaborate on an executable text.
But almost all approaches to writing software assume the absence of
such collaboration.
How do software writers and users collaborate without a shared
executable text? There are two answers.
In formal-methods software projects, analysts and users collaborate on
a non-executable description of the machine behaviour, usually called
the 'specification'. It is likely to be substantial, detailed, richly
structured, and to reflect extensive thinking, discussion and review.
Not being executable, it is untested.
Legislation gets 'executed' in courtrooms; and is impossible to test
before it becomes law. Until a case is brought before a court, there
is only opinion as to what it means. Occasionally the drafting process
gets this spectacularly wrong, as in =A7138ff of Britain's Serious
Organised Crime and Police Act 2003, which, a court ruled, do not
apply to the one anti-war demonstrator they were clearly intended to
restrict. These exceptions are unusual. In the general case, framers
of laws know pretty well what they will mean in a courtroom. Indeed,
this must be so for laws to govern public behaviour.
Similarly with a screenplay. Screenplays can and do change radically
during principal photography. But any producer in Hollywood can read
one and estimate its production costs. The screenplay suffices to
encode agreements about story, characters and production costs.
Being untestable is not fatal to screenplays or draft legislation.
Politicians and laymen can know with some confidence what untested
legislation means. Movie producers can envisage a movie from a
screenplay. A formal-methods software project pins its entire hope
upon users and developers being able to read a specification with
similar success.
Or, to put the same point another way, a specification is 'executed'
by the programmers, and formal methods depend upon users and analysts
being able to envisage with sufficent clarity the result of this
process.
There are strong reasons for doubting they can.[1] Computer systems
are very hard to envisage. There are tools, such as UML, that help,
much as storyboards help envisaging movies. Individuals will have a
detailed grasp of partcular components or aspects. But in the end, as
David Cronenberg said, "You make the movie to find out why you wanted
to make the movie."
Agile developers have the second answer. They reason that effort
expended on a non-executable and untestable description of the desired
system is better invested in tight cycles of writing and testing
software =96 the executable text. Like screenwriters and law-drafters
they will discard and rewrite much. But communication the users will
be better, supported by running software. They expect to deliver
usable software sooner than with formal methods.
All forms of Agile seem radically to shorten communication paths,
spatial and temporal. Meetings are short and may be conducted
standing. Developers work close to each other and to user
representatives. Features are added and reviewed in weeks.
"Pair programming" is a celebrated practice of XP, a prominent Agile
approach. In it, pairs of programmers collaborate on the executable
text (sorry, the software) to raise the quality of the writing.
In a recent successful project at Britain's largest insurer,
programmers paired with senior clerical workers, often revising arcane
domain logic together. We had started with the XP model of fortnightly
development cycles. But collaborating on the source code collapsed the
time required to make and test a change to under an hour in most cases.
[2] It became common for developers to finish the day with no work
unfinished. We stopped formal status reporting. We stopped attending
project meetings unless the users wanted to consult us about specific
changes. In November and December 2005 our group of 4-6 programmers
released 200 changes to the application.[3]
We became studiously unhelpful about predicting progress once we found
user management would accept rapid progress and what's-next
flexibility in place of forecasts. One story illustrates the power we
had placed in their hands.
A division of 25 skilled workers in another city had long been thought
to be doing work that could be assimilated by our now-automated
division. However, no one had ever authorised an IT project to analyse
this. One Monday a manager and a senior clerk from our division went
there to take a look. With their deep domain knowledge they were able
to see that the differences between their work and ours was indeed
minor. They announced that our division would be able to take over
processing from the following Monday. Back with us the following day
they worked with us on the changes, which we tested and put in
production that afternoon. For the rest of the week we resumed our
usual development work. The next Monday two clerks took over what was
previously the work of 25 in the other city. My favourite part of the
story: our users, with no software development experience but working
with us, had not even phoned in to discuss the changes.
Collaborating on software with non-programmers is different from the
largely unsuccessful work on 'natural language programming' popular in
the 1970s. That had the goal of allowing non-expert writers to write
programs. Our practice followed the collaborative writing model I've
described above, pairing domain experts with expert writers.
Nor is it new. Iverson at IBM in the 1960s started an Expository
Programming initiative[4][5] that seems never to have moved from
academic to commercial use. Something similar has emerged
independently in current interest in Domain-Specific Languages (DSLs)
and 'little languages'.
Hernik & al.[6] report that using a DSL (ie collaborating with users
on an executable text) can be very productive, but it is difficult to
predict its value to a given project. So one would prefer to try using
a DSL without investing much. Happily, there is a way to do so that
costs little in time or money: embedding it in a general programming
language. Unfortunately, only some programming languages can support
the required semantic density[7], and Java is not one of them.[8]
Agile approaches radically shorten communication paths and feedback
loops. (Waterfall projects do have the same feedback loops, but they
traverse months and years, reflecting the trust placed in the
specification.)
With embedded DSLs, users and developers can collapse those already
shortened paths by yet another order of magnitude. The results are
insanely productive. But who knows? The effect isn't observable in
Java.
Which brings us back to your point. Despite Ward Cunningham's work on
a language-independent test framework(fit.c2.com), it is unsurprising
to find Agile development approaches insensitive to differences
between programming languages.[9]
Stephen Taylor
editor@[EMAIL PROTECTED]
"The Experience of Being Understood", Stephen Taylor
Requirement specification looks a lot like language acquisition.
Reflecting on what Wittgenstein had to say about language acquisition
suggests an unusual software development practice.
http://www.5jt.com/articles.php?article=3Dbeingunderstood
[2] "Pair Programming with the Users", Stephen Taylor, Vector 22:1
Why write specifications when you can collaborate with the users on
executable code? Introduces the concept of 'semantic density' in
constructing Domain-Specific Notations.
http://www.vector.org.uk/archive/v221/sjt221.htm
[3] "Software Development as a Collaborative Writing Project" Brian
Bussell, Director of Pensions, Norwich Union Life and Stephen Taylor
Writing software is more like drafting legislation or writing a
screenplay than it is like engineering. Paper presented at XP2006,
Oulu, June 2006.
http://www.5jt.com/articles/40440021.pdf
[4] "Expository Programming" by Paul Berry, Vector 22:3
Iverson used APL in the 60s to develop readable, executable models of
key processes in different scientific fields
http://www.vector.org.uk/archive/v223/berry.htm
[5] STARMAP was a well-known product of Iverson=92s Expository
Programming initiative, an executable model of calculating the
positions of the objects visible in the night sky. SolitaireGame is a
recent example of Expository Programming in Dyalog.
http://aplteam2.com/aplwiki/moin.cgi/SolitaireGame
[6] "When and how to develop domain-specific languages", M. Hernik, J.
Heering & A.M. Sloane
Centrum voor Wiskunde en Informatica
http://ftp.cwi.nl/CWIreports/SEN/SEN-E0517.pdf
[7] "Semantic Density", APL Wiki
http://aplteam2.com/aplwiki/moin.cgi/SemanticDensity
[8] "DSL entry cost in Java" Ville Oikarinen, private communication
An evaluation of the Java language as a tool for creating and using
DSLs. The focus is on features that make DSLs impractical. Also an
effort to create a template for analyzing different DSL usage
scenarios and how other languages support them.
[9] I mentioned to Beck my first reaction to "eXtreme Programming
explained" was astonishment that C++ and Java could be used with such
agility. He grinned wolfishly, and hoped he might get to write in
Smalltalk again.
|
