RE: [unrev-II] More Inscrutability

From: Garold L. Johnson (
Date: Sat Dec 23 2000 - 16:07:28 PST

  • Next message: Eric Armstrong: "Re: [unrev-II] Attribution"

    I have adopted a design principle called WYGINS (What You Get Is No
    Surprise), also known as the “Principle of Least Astonishment,” to try to
    prevent just such occurrences. Alas, I have not always been successful!


    Garold (Gary) L. Johnson

    -----Original Message-----
    From: Dennis E. Hamilton []
    Sent: Saturday, December 23, 2000 3:11 PM
    Cc: unrev-II Group
    Subject: RE: [unrev-II] More Inscrutability

    "You have been snagged by the inscrutability of distributed mechanisms.
    E-msil systems
    in distributed operation are my favorite source of system-incoherence


    OK, here are some expansions from my private freeze-dried language:

    distributed mechanisms:

          mechanisms in which an end-to-end behavior is accomplished by the
    coordinated use of individual processes in communication with each other.
    The orchestration of coherent behavior may depend on (out-of-band)
    assumptions about end processes that aren't assured to hold.

          helpful, right? Let's move to illustration by example.

    e-mail systems operate via a distributed mechanism. The message passes
    through a number of computers, all of which are likely to make modifications
    to it. Your mail-originating software may have built-in assumptions about
    what my mail client will do with fancy things, and what the intermediaries
    will leave intact.

    Simple example of inscrutability: If you send me a text message where the
    first word in the body is "begin" chances are I will receive a blank message
    no matter how much text follows that word. It is certainly a bug in
    software close to my end. On the other hand, what are the odds that you and
    I could figure it out?

    In the early days of e-mail, servers and clients would rewrite
    message-header elements so that recipients would see valid addresses that
    could be used in making replies from their point of e-mail introduction. To
    this day, there are mail systems that get this wrong and mangle the
    addresses presented to the recipient, causing replies to bounce as
    undeliverable or as for unknown recipients. I had to troubleshoot a problem
    like that in the past year. I don't use that e-mail service any longer.

          system-incoherence examples

    uh, examples of system incoherence?

    This one is in English. Do my two examples illustrate what I mean by
    incoherent behavior? I mean it as a system effect that arises in the
    interaction of distinct subsystems.

    Here's another example.

    I start receiving mail from a colleague which arrives as plain text with
    lots of markup in it: appearances of <h1> ... </h1>, and other noise. Being
    a geek, I suspect he is using some HTML-formatted message, but my mail
    client is not recognizing that the text message has HTML markup in it. I
    reply to the message, including his message in the body of my plaintext
    message, saying that I find it hard to read. He sees my reply, but the
    markup that is echoed in my reply displays just fine in his client, and he
    says it looks just fine to him! If I send him a message where I am talking
    *about* HTML markup tags, he will not see what I intend for him!!

    That's incoherence. That's inscrutability.

    As far as I know, every example I have is one in which an implementation
    suddenly shows through in an inexplicable way, confronting someone in no
    position to understand it nor to do anything about it.

    Here's an example from the control panel of a very expensive copier:

          "System Fault. Output may be lost. Continue? Yes/No"

    I have become a big fan of Alan Cooper's "The Inmates Are Running the
    Asylum: Why High-Tech Products Drive Us Crazy and How to Restore the

    -----Original Message-----
    From: Henry van Eyken []
    Sent: Saturday, December 23, 2000 14:09
    Subject: Re: [unrev-II] More Inscrutability


    Excellent contribution!

    The matter of inscrutability has not gone altogether unnoticed. Frankly, I
    run into it
    just about every time I crack open a book about computing.

    This webmaster's attempt at coping with the problem is found on our home
    page, , where terms readers might encounter for the first
    time are
    explained in a footnote.

    Three forms of inscrutability stand out in my mind:

    1. unexplained abbreviations
    2. unexplained terms
    3. a style of writing that I personally identify with the term "freeze-dried
    Here is an example:

    "You have been snagged by the inscrutability of distributed mechanisms.
    E-msil systems
    in distributed operation are my favorite source of system-incoherence

    I find it hard to fathom what precisely is meant by these sentences. What is
    meant by
    "distributed mechanisms"? What by "e-mail systrems in distributed
    operation"? What by
    "system-incoherence examples"?

    For more about freeze-dried English, see: goes it loose

    I do appreciate your forcefully bringing to our attention the pain on the
    brain caused
    by inscrutability.


    "Dennis E. Hamilton" wrote:

    > I am a visitor here because of a cross-posting that Eric Armstrong made
    > another discussion list.
    > Having made this random entry, and musing about systems inscrutability and
    > incoherence, I can report that I had a heck of a time figuring out the
    > following terms, which are used heavily in this setting:
    > OHMS - Open Hyperdocument System
    > was the easiest
    > NIC - Network Improvement Communities
    > was the next easiest
    > DKR - Dynamic Knowledge Repository
    > was very tough until I searched the eGroup
    > SDS - I gave up on, it is used so heavily that I despair of
    finding a hit
    > that is actually definitive.
    > So, here's a test problem for and the unrev-II group:
    > What is the definition of "SDS" as used here?
    > If I came in at, how would I have found it?
    > If I came in at the eGroup, how would I have found it?
    > - - - - - -
    > What's the point?
    > 1. I am struck by the degree to which tacit knowledge infects most
    > contexts. It is easiest to notice that when the context is unfamiliar.
    > am sure that visitors to sites I compile material on would be able to give
    > me a disappointingly-long list of undefined terms and undocumented
    > assumptions that baffle them.
    > 2. If an OHS/DKR is intended to support explanation (my test of any
    > knowledge-based system), it would seem that induction of conceptual
    > frameworks, contexts, and maybe even paradigms becomes important. With
    > little exposure to this discussion, I do notice that a lot of the
    > implementation conversation is about pretty low-level plumbing (e.g., XML
    > carrier, granularity of links, and frames versus hierarchies). I love to
    > fuss about infrastructure too.
    > 3. Maybe what is needed is some kind of challenge problem that could be
    > done on an existing corpus (such as the unrev-II collection) and
    > achievement of some measure of DKR acceptability.
    > -- Dennis
    > AIIM DMware Technical Coordinator
    > AIIM DMware
    > ODMA Support
    > ------------------
    > Dennis E. Hamilton tel. +1-425-793-0283
    > fax. +1-425-430-8189
    > Community email addresses:
    > Post message:
    > Subscribe:
    > Unsubscribe:
    > List owner:
    > Shortcut URL to this page:

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    eGroups Sponsor
    Click Here!

    Community email addresses:
      Post message:
      List owner:

    Shortcut URL to this page:

    This archive was generated by hypermail 2b29 : Sat Dec 23 2000 - 16:32:21 PST