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

[Thomas Passin <list1@tompassin.net>]

Hi, Steve!

On 12/2/2013 9:11 PM, Steve Newcomb wrote:
> 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.
It's not just the government, though.  If you follow The Daily WTF site 
for a while, you'll see that non-government companies can be just as bad.

I can give you a more concrete example of the separation of these three 
activities.  Take an hardware item destined to go into a submarine.  I - 
my company at the time - have built such items, reactor related things 
for nuclear subs.  If you or I go to the hardware store and buy a tool, 
but it doesn't do what it's supposed to, we find out quickly and usually 
can return it.  But for our submarine item, even if there is an existing 
supply contract (and there usually is), the contract and specification 
were written and the item developed and qualified by (or for) one 
agency.  The procurement may have been done by another.  The item is 
shipped to and stored by yet another organization.  Finally, perhaps 
many years later, the item is requisitioned and delivered to a ship, 
whose personnel have to use it.  And, for our sub, it has to work.  They 
can't take it back, and they can't rework it.

And, for our subs at least, all such items by and large do work - we 
know because the subs sail, and the reactors don't blow up or melt.  But 
I will tell you that none of it worked right the first time.

It's not the government's fault, but that item *cannot* be procured, 
developed, tested, qualified, and used all by the same people or 
organization.  The areas of expertise are too diverse, and the span of 
time between development and use is too large.

Well, here we're mostly talking about software systems, but it's not 
that different in this regard.  So we *want* to have things work as if 
developed and used by the same person or organization, who as you say, 
can take responsibility and have a personal stake in the outcome.  But 
we can't.  The name of the game, then, is to invent ways to come as 
close as possible to the ideal.

Now, it's certainly the case that the government (whichever one it is, 
not just the Federal government of the US) can mess up each and every 
level we've pointed out above.  And it often does.  That only makes 
things worse.

Back to the submarine example, we came close to your ideal, as close as 
we could anyway, when Rickover developed the nuclear submarine.  *He* 
was the one in charge, he had the authority and the backing, and 
apparently he had good managerial skills.  And every Tuesday without 
fail we and every nuclear contractor had to send a letter addressed to 
him *personally* that would begin

"Dear Admiral Rickover: The following items are critical to the 
development of XXX:"

If there were no critical items, you had to write "None".  Otherwise you 
had to state the critical item or items, it's expected delay, what has 
changed from the last letter, and who was responsible in the government 
for making it happen.

This letter was a contractual requirement.  (As an aside, at first the 
letter had to be addressed "Dear Vice Admiral Rickover".  When he 
finally got promoted, we were notified to change it to "Dear Admiral 
Rickover").

Maybe this is the way to handle these complex, important systems.  It 
worked for Rickover.  Or maybe this can only work when you have a truly 
exceptional person like Rickover or Kelly Johnson.