Re: experts

["Simon St.Laurent" <simonstl@simonstl.com>]

At 01:07 PM 3/28/01 +1000, Marcus Carr wrote:
>This is getting silly - if you check dictionary.com it defines an expert as "a
>person with a high degree of skill in or knowledge of a certain subject". I'm
>at a loss as to who could possibly be more appropriate. You don't want rich,
>self-interested parties and now you don't want people with actual topic
>understanding either - who do you want to do the work? Experts are typically
>experts because they work in the field.

That's the obvious reason why 'experts' are given special privileges.

I'm suggesting, however, that it may be time to question whether experts, 
by virtue of knowing more than the average developer, may in fact know too 
much.

To over-generalize, here's what the problem looks like:

- Experts are very good at definining processing layers.

- Experts are very good at achieving optimization by blurring those 
processing layers.  (They know where the benefits are, how to achieve them, 
and how to stay out of trouble.)

- Those experts (perhaps that kind of expert) are willing to combine 
multiple layers of functionality in a single process.  They know how to 
make it work safely and efficiently, and think that even the 'bozos' should 
be able to figure it out.

- The result?  Specifications which do too much (and sometimes, even 
simultaneously, specify too little.)

I'd put XML 1.0 forward as a canonical example which has succeeded 
_despite_ such problems.  Did DTDs really have to be mashed into the XML 
1.0 spec?  Did all of that have to be _one layer_ of processing?  No.  Has 
that helped the learning or adoption curves?  I really don't think so.  At 
least XML tried really hard to make life easier than it had been, and for 
that I think we're all quite obviously grateful.

Namespaces suffered from a similar flaw.  They added substantial processing 
and readability issues to documents by using the inherited attribute 
mechanism, and relied on URIs, a spec that only URI experts really seem to 
like.  There are 'safe' and easy ways to use namespaces, but we've spent a 
few years figuring out what they were.  The spec seems to assume that 
readers can figure that out.  Yes, the foundations are simple, but not in a 
way that makes much sense for a good long time.  Namespaces are useful, and 
maybe they'll seem obvious in five years, but they're stil pretty strange 
creatures to an awful lot of developers.

I'd suggest that similar flaws afflict many of the specs coming from 
various organizations, and that 'bozos' like me (aka at my programming 
skill level) tend to be the unfortunate victims of the time and effort 
wasting caused by such flaws.

Hence, my suggestion that we consider other approaches to 
design-by-expert.  It doesn't have to mean design-by-moron, but it does 
require a change in perspective.



Simon St.Laurent - Associate Editor, O'Reilly and Associates
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books