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

[Stephen Cameron <steve.cameron.62@gmail.com>]

On Tue, Dec 3, 2013 at 2:24 AM, Thomas Passin <list1@tompassin.net> wrote:

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.

No, this is the opposite of what I was trying to say.  The examples that you give are best divided into a design phase and a construction phase. Much software development is different,  it requires working with the end users from start to delivery, as the Agile approach advises, the only equivalent building phase, in the sense that there is a team of builders working from a plan, is the compiler/interpreter.

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.

Agreed, you do have to understand the problem domain and how you go about doing so is the key to success.  The real question is: should you try to document requirements or just start coding and do the design in the code. Domain Driven Design says yes, but with constant refactoring to improve your model as you learn more about the domain. Modelling is essentially what OO languages were invented to do. The same approach can be applied to data-modelling in a data-driven system.

 

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.

If the task is routine the first prototype will likely form the basis of the final system.

_______________________________________________________________________

XML-DEV is a publicly archived, unmoderated list hosted by OASIS
to support XML implementation and development. To minimize
spam in the archives, you must subscribe before posting.

[Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
subscribe: xml-dev-subscribe@lists.xml.org
List archive: http://lists.xml.org/archives/xml-dev/
List Guidelines: http://www.oasis-open.org/maillists/guidelines.php