Lists Home |
Date Index |
From: Michael Kay [mailto:email@example.com]
> By participating in some n of successful and
> failed standards efforts in a knowledge domain
> in which they are competent.
>So in each generation we need to create a few unsuccessful standards, in
>order to train the people who will create the successful ones of the
Yes. That's the cost of continuity. As best we can, we write down what
we learn, but it comes with the warning that the past is not always
That for example, is one reason these lists exist. It helps if the
leadership does diligent research so they have a good handle on what
the issues will be. XML is a good example where the precepts were
fairly informative even if they fall apart in specific cases (verbosity
does matter but there are always maps).
Risk is real but manageable. If it isn't, it isn't worth doing.
>Quite honestly, I don't think any failures of standards that I know of can
>be put down to the incompetence or amateurism of individuals. Teams, yes:
>two highly competent individuals pulling in opposite directions is not a
>good formula. And a match of people to the task: sometimes you want
>thoroughness and sometimes you want it cheap and cheerful.
It depends on leadership. If the standard really fails,
leadership may have to suck it up. So, one can say that individuals
do fail, and that training leaders has high value. Being able to
pick a team is better than culling unknowns. That is why I say
hire professionals when possible. When forming bands, one can cattle call
players but it is better to hire known pros if the gig
is understood. It saves time, conflict, and the gig itself. One
can conceive of spec writing and standards writing as performance,
so chops, attitude, and practice matter. Unfortunately, too often
we bless the notion that a good standard can come of whoever shows
up. It can work but the odds aren't as good. So again, if someone
is asking me for a professional piece of work, top flight players
cost top flight money. If they want cheap, the weekend warriors
and the garages are full of willing players. If they do pay me
and I fail to put butts in seats, it is my fault.
So as you say, good requirements matter. If they just want noise
to fill the space so they can open the club, almost any set of players
will do. If they want 'young professionals making three figure salaries
who like Jagermeister and occasionally purchase cocaine in the back office',
get top jazz musicians with a very foxy front singer, and BTW, I decline.
I don't believe in poisoning clientele for profit.
>But mostly, it's down to getting the requirements right. ODA and X.400
>delivered all the requirements that people said they needed, and then the
>same people went out and bought something cheaper. The engineers who did
>work were highly competent and professional, it was the companies funding
>them who got it wrong.
The 'who benefits' question is germane. A standard for a pre-existing
market should advance that market by promoting quality or interoperability.
A specification should create a market which might include taking customers
from an existing market. Someone has to pick the metric of success and that
is usually the customer. MP3 has competitors but none are denting it much
despite the encumbrances of MP3 because the vendor is glad to pay for that.
Windows wav files rule in the LotsaFidelity formats but the market for the
devices is much smaller because the distribution is on mass storage.
I think XML succeeded because the W3C with the exception of Dan Connoly
was clueless about markup and the subset of markup professionals who
understood hypertext were quite adept. I advise people who want to
write specifications to stay under the radar until they have running
code. Unfortunately, the lesson promoted is to get all the buy in
they can before they have even gotten a solid team together. It's a
bad plan. Jam first. Pick the band. Then rehearse like mad until
you are ready to play a gig somewhere away from the target customer.
Then cull the songlist and go get the money.