[
Lists Home |
Date Index |
Thread Index
]
Title: RE: [xml-dev] Resistance is not Futile because Change is Inevitable and You Mig ht As Well Get Paid for Implementing It
Well said, sir.
Pointy haired managers want the technology to be so simple that even a pointy haired manager can implement a complex system integration, then he can send all his expensive programmers home.
His expensive programmers strive to achieve this but inherently introduce vast complexities because allowing pointy haired managers to write enetrprise level software using point-and-click technology is not trivial (well, as far as I know, no one's managed it yet).
So the programmers can't go home. In fact, they are needed even more to control this added complexity.
And pointy haired managers still can't write software using PowerPoint compilers.
Which is a Good Thing(TM).
-----Original Message-----
From: Bullard, Claude L (Len) [mailto:clbullar@ingr.com]
Sent: 12 June 2002 15:55
To: 'bryan'; xml-dev@lists.xml.org
Subject: [xml-dev] Resistance is not Futile because Change is Inevitable
and You Mig ht As Well Get Paid for Implementing It
How it will go:
1. The current technology is failing somewhere
and there are complaints from customers.
2. Because of perceived even if bogus lack of
powerful features in the currently applied technology,
a pointy haired manager will appoint a tiger team
(a marketing name for a committee of people anxious
to impress their inner peers and their managers) to
come up with alternative technologies. Meanwhile he or
she will consult with his or her inner peers about the expected
results.
4. The pointy haired manager will decide to use the
technology his or her inner peers suggest will be successful
in the eyes of the manager's manager's inner peers.
5. The technologists will go forward grumbling but
productively. Along the way, they will
use a technology feature to sub-optimize a process
or production because they want to impress their
inner peers and the managers of their inner peers.
6. The sub-optimized process will become important.
Meanwhile, the feature it depends on will either be
changed by the group responsible for specifying it
because one of its members wants to impress his or
her inner peers with their deeper and more impressive
technical acumen.
7. An implementation release two versions post the
changed specification will contain a bug due to an
ambiguity in the specification change language.
8. This bug will cause pre-spec'd software to become
incompatible and thus fail on current and now "standard"
versions of the documents.
9. This failure will go undetected until fielded and
will result in complaints from customers who cannot
understand why a product that worked in accordance
with their expectations is now failing.
10. Go to step 2.
One wants to believe in rationality and completed projects,
but one learns that rationale is a viewpoint among viewpoints and
that the viewpoint of the creator is simply relentless
change. So project by project, we implement change and
that is not the same as progress.
Get used to it. It is why we all have jobs.
len
-----Original Message-----
From: bryan [mailto:bry@itnisk.com]
Recently my boss received an email, passed on from a business partner
who was passing it on from a friend of his in New Zealand who wanted to
switch all their old dtds to Xml Schema and wanted some pointers. I
pointed to the beginning of the Xml Schema considered harmful thread,
pointed to a bunch of other Schema resources, went into depth as to what
the benefits of RELAX-NG and Schematron were to my mind as opposed to
XSDL and so forth. Well for reasons that I think are partly political I
believe most of my RELAX-NG and Schematron stuff was cut from the
finalized communication, in the interest supposedly of not overwhelming
the poor guy trying to come to grips with Xml Schema, who I suppose will
now be overwhelmed by attempting to come to grips with Xml Schema.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://lists.xml.org/ob/adm.pl>
The information transmitted by this e-mail message is intended solely for the use of the person to whom or entity to which it is addressed. The message may contain information that is privileged and confidential. Disclosure, dissemination, distribution, review, retransmission to, other use of or taking any action in reliance upon this information by anyone other than the intended recipient is prohibited. If you are not the intended recipient, please do not disseminate, distribute or copy this communication, by e-mail or otherwise. Instead, please notify us immediately by return e-mail (including the original message with your reply) and then delete and discard all copies of the message.
Although we have taken precautions to minimize the risk of transmitting viruses we nevertheless advise you to carry out your own virus checks on any attachment to this message. We accept no liability for any loss or damage caused by viruses.
| 