Re: A failure to communicate

I'm torn between several positions on this :)

Using a pragmatic collection of SSADM, Yourdon etc as a software engineer
in 88-92 in large companies, I realised that documentation itself was
relatively useless, but merely a tool to help your customer reached an
informed decision, choosing between well-understood and well-defined
possibilities. SAying "Is this how it is" in order to generate "Well,
almost, but that doesn't go there, that only sometimes goes there..." etc
only reveals a lack of analysis of and empathy with the customer's
activities, goals etc.

In a start-up, supplying hypermedia projects 94-8 to a variety of
customers, I saw that the choice of diagrammatic conventions, storyboards,
etc was based upon my mastering the client's language of communication -
finding ways to express our ideas in their visual images tec. It's not
hard to do this - ask to see an organisational structure chart, ask them
how they make the case to their senior management or to other business
units for a particular course of action. I used tools like Authorware (at
the time about 5 times as productive as Director/Toolbook) to create
extremely rapid prototypes and refine needs.

As the years progressed, the IT department gradually began to reassert a
degree of control over innovation, mainly as a result of the preparations
for y2k being fairly predictable in most of our customers by around 97.
The main problem became the marketing intranet or the training CD-ROM that
swamped available bandwidth and/or introduced incompatible new hw and OS.
So now the game became "in which aspects of (what became) UML do they
communicate".

When I switched to academia and discovered the UML effort, and the careful
thought that went into the connotations of everys ingle arrow, box,
circle, etc, I realised that here was now a universal language that every
(large) customer would eventually learn. The "eventually" bit is still not
resolved, but, as we saw at a symposium on Usability and UML last year
(see http://www.dcs.napier.ac.uk/~mm/uu2002/ for abstracts etc), there are
lots of potential ways to use or extend UML to meet these needs.

Perhaps the fundamental truth is that methodologies are not there to
provide a do it by numbers approach. They are there to
a) help those desiring the solution to understand what they need as well
as want
b) help those providing the solution to build their understanding of, and
empathy with, the objectives of the community for whom they design the
solution
Everything else is logistics...
Tom McEwan
Napier University

    --------------------------------------------------------------
     POSTINGS (in plain text): [email protected]
           SUBSCRIPTION CHANGES:  http://lists.syntagm.co.uk
            (or send email to mailto:[email protected])
    --------------------------------------------------------------