Hi Keith,

> I do agree with you about the unfortunately limited
> application of 
> systems theory to management in many businesses,
> though ideas such as 
> those of Senge and Capra /have/ had some influence.

I think that systems theories as they are today are
not sufficient.  For instance there are
disappointments in applying complexity theories to
business even though some useful applications. 
Complexity theory remain symbol systems while living
systems must consider both symbol and matter aspects -
Pattee's semantic closure.

> However, I can't agree with you about removing
> iteration!  Iteration is 
> not just caused by system errors or poor
> communication of requirements, 
> it is caused by changing business needs and evolving
> business processes.  The ascendance of Agile
methodologies in almost every field 
> bear witness to the effectiveness of bringing
> interation to the 
> forefront and basing development practices around
it.

The issue is not much in iterations but in the
context.  If we talk about SW development agile
methodology, then each iteration (normally one to four
weeks) is a miniature project of its own and includes
all tasks neccessary from requriement to coding to
release a product.  The problem is its theory and its
Newtonian-Cartecian worldview.  Cutting a rat in half
we do not get two rats, we get a dead rat that loose
all essential properties of a rat.  Agile method cuts
the rat fifty times?  The more it cuts the more it
cause problems (in name of chaning requirements).
Agile method does not adapt changes rather it
generates unnecceary problems (described as changing
requirements) artificially and have to use more
resources to fix them.  

I don't know if you are familiar with 75/50 rule.  At
75% of planed schedule, only 50% of functionsalities
are implemented. At this mark, it is the implemented
functions that cause problem.  At the mark of 75% of
planned schedule, every added new feature cause a
change in the baseline.  The systems enter into
maintenance mode unofficially.  The shipdate is
determined by the impact of change in baseline in
adding new features.  That's why coders spend 80% of
their time fixing errors (according to NIST).  Agile
methods induce, not reduce this 75/50 maintenance mode
for its mechanistic worldview!

> In fact, making an analogy with living systems,
> evolution is just a form 
> of iterative development, isn't it ...

I would not say making analogy with living systems. A
business is a living system, a third order
autopoiesis.  As such, business living system relates
to other life forms (1st and 2nd order autopoietic
systems) in form of homology, not analogy or metaphor.

It will have iterative processes but not cut the
project into miniature projects as the method of
inquiry invented three hundred years ago by Descartes.

Jerry
> -- 
> 
> All the best
> Keith
> 
> http://keith.harrison-broninski.info
> 
> Jerry Zhu wrote:
> 
> >--- Keith Harrison-Broninski wrote:
> >
> >  
> >
> >>Yes, exactly - though I assume by "doing things
> >>right" you don't mean trying to build the perfect
> >>system first time round (an impossibility for
> >>various reasons), but rather trying to collaborate
> >>/effectively/ in an ongoing system development
> >>process.
> >>    
> >>
> >
> >I do mean build the perfect system (not best but
> error
> >free system) first time round.  Really.  It is the
> >"ongoing system development" that trubles me for
> the
> >waste on the predicable and avoidable errors. RUP
> uses
> >iterations to correct errors (ongoing systems
> >development?) that takes 80% of developers' time
> >according to NIST.
> >
> >I do agree with your "impossibility" for today's
> >prevailing worldview and associated methodologies. 
> 
> >
> >Herbert Simon (inventor of hierarchy theory, Norbel
> >Laurate) proved mathematically that hierarchies
> will
> >evolve much more rapidly from elementary
> constituents
> >than will non-hierarchic systems containing the
> same
> >number of elements.  Today's business approach is
> >based on mechanistic worldview rather than living
> >systems' worldview. The problem is neither in
> >technical nor in the process but the worldview, our
> >conception of the world.  When our worldview is out
> of
> >date our behavior they drive is out of date.  
> >
> >Best regards
> >
> >Jerry Zhu
> >
> 


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam
protection around 
http://mail.yahoo.com 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 





 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/service-orientated-architecture/

<*> To unsubscribe from this group, send an email to:
    [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/
 


Reply via email to