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

[Steve Newcomb <srn@coolheads.com>]

Tom, I'm trying to understand how to act on your excellent observation.

I think I'd put it a bit differently.  I think the fatal flaw in
government contracting, as I have frequently experienced it, is very
simple indeed.  It takes three things for anyone to succeed in any project:

(1) Responsibility for making it work.

(2) Authority for making it work.

(3) Ability to make it work.

In my experience, these three essentials are almost never left in the
same hands, and their separation from each other is the reason for
failure.  Putting them all in the same same hands may not work, but
separating them will surely not work.

There's another way to put it:

"If you want something done, get somebody who can do it and wants to do
it, supply everything needed to get it done, and then be *sure* to get
out of the way."

And here's a third way to put it:

"Commission the right artist," i.e., an individual or set of individuals
who function collectively as a single artist, and whose art is congruent
with the task.  And then get out of the way.




On 12/02/2013 08:12 PM, Thomas Passin wrote:
> On 12/2/2013 6:13 PM, Ihe Onwuka wrote:
>> That would be Gall's 3rd System Axiom.
>>
>> http://www.laetusinpraesens.org/docs/systfail.php
>>
>> Even with a good clear set of requirements,  analysts and designers
>> dilligent and good enough not to specify/implement an over-engineered
>>  solution are thin on the ground.
> 
> Anyone who has been in engineering or manufacturing for any significant
> time should know that things ... systems ... whatever that has any
> complexity ... hardly ever work as expected right off the bat.  Things
> have to be tweaked, fixed, redesigned, reworked before they work right.
>  A new ship, for example, will likely have thousands if not tens of
> thousands of item on its punch list when first launched.
> 
> That's true about software, too.  Anyone who thinks a software system is
> going to work right at first is a fool, there's no way around it.  But
> the contractual and managerial means that would provide for the
> evolution to a correctly working system - and these means have to work
> all during the project, not just near the end - we hardly ever have them.
> 
> This would be true even if the requirements were fully known and
> properly worked out from the start, and the development team were
> totally capable and understood how to use the tools provided.  But we
> know that's hardly ever the case, too.
> 
> When legal and political matters are involved, they make it much harder
> because they can't be flexible where flexibility is needed.
> 
> As I think about this, it seems to me that what is needed is research
> into new methods of contracting for and managing software systems.  It's
> not that a new methodology will solve everything.  It's not that a new
> modeling tool or a new programming language will solve everything.  It's
> not even that better programmers will solve everything.  The
> social/managerial/contractual base is completely inadequate.
> 
> Hopefully what emerges will be simple.  Enterprise Architecture was a
> apparently good idea that grew out of control into an unmanageably
> complex monster.  And yet at its simplified core, it still can have value.
> 
> _______________________________________________________________________
> 
> 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