Re: [xml-dev] Re: XML As Fall Guy

From
Thomas Passin <>
To
"" <>
Date
2013-12-02T15:24:30Z
ID
<>
Thread
Re: [xml-dev] Re: XML As Fall Guy
On 12/2/2013 2:09 AM, Stephen Cameron wrote:
> I think you are getting to the heart of it, but the analogy I like is
> making a movie, the final result is very open-ended and coordinating the
> activity of getting a result very complex, also, whether the end result
> is a success is very much dependant on intimate knowledge of the humans
> who will view (use) the outcome.

I think that a better analogy is a large construction project like an 
office building or a large bridge.  They often run over budget and 
schedule, and often develop unforeseen problems.  Some of them are 
almost exactly like previous ones, and some have many new elements. 
During construction, unexpected problems arise, and once completed, 
usage patterns may turn out to be quite different from those 
anticipated.  Many of the implementation details are routine and 
implemented by tradesmen who don't know much about the overall architecture.

> I think we have to abandon the idea of a design and an implementation
> phase, its all basically design, I'd even go so far as to abandon UML as
> a design tool, to the extent that its use is premised on this
> separation. Building and testing prototypes seems to me to be the means
> to 'explore' the space of possible solutions.

Well, you have to understand the problem domain - what the user needs - 
the requirements.  It helps a lot to devise a model that covers the 
requirements.  In fact, it's a good place for an object-oriented 
approach.  You may or may not decide to do actual implementation using 
objects, but the highlevel, object-oriented requirements design is a 
good starting point.

To what extent you can just start implementing and prototyping without 
design depends on how new and different the task is, and at what level 
you are working.  The less routine, the more you will need to design, 
experiment, and prototype.  The more routine, the more you can just dive 
in.  But to some extent, implementing without design is possible because 
you have in your head the experience of making a lot of previous designs 
and knowing how they were implemented.  The design work was actually 
already done, but implicitly.