[unrev-II] Simon's Paper

From: Eric Armstrong (eric.armstrong@sun.com)
Date: Fri Oct 19 2001 - 12:30:07 PDT

  • Next message: Jack Park: "[unrev-II] Important Quotes"

    Simon wrote a highly thought-provoking paper, which
    I tried to attach, but Yahoo groups rejected it as
    too big. Below are the notes I sent him on it.

       Perhaps you can make it available on the web
       somewhere, or send it to folks who request it.

      * "DR" stands for Design Rationale system.
      * The paper begins on page 603

    Over all comment
    Extremely good and provocative paper.

    p. 604
    So far, I like the approach and the decision to evaluate claims
    that are being made. Good idea. But...

    There is a need to distinguish between capturing DR (why) and
    capturing the process by which design decisions are made. The
    process-history is of interest the psychologist and design
    anthropologists -- who want to understand the mechanisms by
    which decisions were made, who decided, and what information
    the decsions was based on.

    The engineer/design-archaeologist only wants to know why
    people did what they did -- or, at least, what they thought the
    reasons were at the time. From a practical standpoint, the
    question of *how* decisions were reached is of no consequence.

    I'm feeling a sense on this page that those two aspects of DR are
    not being distinguished. It may not matter, for the purposes of
    the paper, Or it may be huge. I'll have a better idea when I see
    where the paper is headed.

    (Granted, some times the notions merge. "We tried this, and then
    we tried that, and none of those approches worked, so we settled
    on thus-and-so, which combines some of the features of each...",
    and notes to that effect, constitute a historical rationale. But the
    argument need not be a "how". It could simply consist of evaluations
    of the first, second, and third approaches.)

    pp. 605-611
    Great survey of who-has-done-what.

    pp. 612-613
    Brilliant analysis of the kinds of claims being made, and the types
    of evidence being adduced. I'm looking forward to reading

    pp. 614-616
    I'm not sure how useful the evaluation of legal argumentation
    methodologies is to evaluating the potential for DR structures.
    The legal domain is totally "unbounded". Every case stands by
    itself, and it is extremely difficult to extract generalitites which
    can be usefully applied elsewhere. The problems that noted the
    results were not easily penetrable by others, and not that
    helpful in clarifying the designer's thinking are, for that reason,
    less useful indicators of the possibilities inherent in the methodology.

    In design, the issues are more restricted, and the cases more
    bounded. It is therefore reasonable to expect that the symbols,
    patterns, and understandings gained from one design will be
    applicable in another area. In other words, over time one could
    build up a argumentation/design vocabulary that would be usefully
    applied in new contexts, and which would help you "read" the
    DR that others had constructed. (In law, by contrast, if you hadn't
    constructed it yourself, you probably wouldn't be able to read it.)

    pp. 632-633
    I have to agree that premature structuring and cognitive overhead
    are major issues with any tool that is devoted to capturing and
    clarifying thought. Done badly, the solution can appear to be worse
    than the problem.

    However, I don't believe that the inadequacy of the tool is a valid
    argument against the method. As an example, I would cite outlines.

    Prior to computers, outlining technique was taught in schools. Some
    of us loved them. Most students hated them. The reason became
    apparent many years later, when I constructed one of the first
    outlining programs ever written. (It was in Basic, and it was extremely
    minimal, but it predated ThinkTank by a year or more.)

    In that process, and in the process of working with the production
    outliner I and my cohorts subsequently developed, I discovered that
    the outliner's truth strength lay in the ability to RE-organize

    It became clear that the issue with outlines as a thought-organizing
    tool derived from the "concrete" nature of the pen and paper
    medium. Those of us with "logical minds", and the ability to try out
    several organzational schemes in our head, loved outline structures.
    The vast majority didn't, because it never came out right, and was
    impossible to change afterwards.

    With a computerized outlining tool at my service, I found myself
    tackling larger problems, easily shifting things about as new organizing
    principles occured to me.

    To bring the moral home, those pen and paper outlines imposed the
    induced "premature structuring". In a more maleable medium, any
    starting organization was as good as any other, due to the ease of
    rearranging material.

    >From the standpoint of cognitive overhead, such hierarchical structures
    are useful precisely because they allow one to "divide and conquer"
    the problem. They also make it easy to see the big picture, so you
    know what the major categories are, and then dive deep into any
    given area to deal with the details.

    A realistically usable DR must retain those advantages. I have written
    elsewhere on how graphic hierarchies have to work to provide the
    same advantages (via nesting). Very few extant systems operate in
    that way, so it is no surprise to me that no graphical representation
    remains useful once a problem gets complex.

    More importantantly, I contend that the major goal of DR system
    should be to *derive* organization over time, and to record the
    final state of the organization, with a record of the justifications for
    each design decision. (Again, I see a difference between the historical
    approach that shows how you got there, and rationale recording,
    that simply describes your reasoning, without going into detail on
    the experiences that led you to those conclusions. Some folks favor
    the former, and I agree it would be useful, as long as the additional
    can remain hidden until it is needed. But in terms of practicality, I
    believe that only the latter is needed for the vast majority of

    p. 637
    A really important point mentioned here. One that is worth highlighting.
         The Design Loop.
             raw problem --> micro problem --> design alternatives

    This is an aspect that the hierarchical structures I'm used to are
    miserable for. There really needs to be a loop, where you drill
    down solving problems, and then leap up to pose new alternatives,
    each of which are linked to the problem(s) they solve.

    Given a rich set of interlinking information, it should even be possible
    for a *computer* to select the most elegant solution, defined as
    the minimal set of alternatives that cover all of the known problems.
    (Note: That "minimal" could be defined in terms of nodes, or it
    be the product of some metric attached to each node, such as a
    time estimate for completion. A business-elegant solution might
    therefore minimize the time-to-complete, while a technology-elegant
    solution would minimize the number of nodes in the solution set.

    Example: Modules A, B, C already exist and could be applied to
    solve the problem in one-day each. Or Module D could be created
    in 4 days, and combined with an unchanged module C to solve
    the problem. The business elegant solution is A'+B'+C', for a total
    of 3 days. The technology-elegant solution is D+C, for a total of
    4 days.

    p. 637
    Good detailed feedback on the frustrations of using IBIS and gIBIS
    at the bottom of this page.

    p. 639
    A good checklist for constructing a design represenation language.

    All in all, an excellent paper that challenges many unquestioned
    assumptions. A worthwhile read.

    ------------------------ Yahoo! Groups Sponsor ---------------------~-->
    Pinpoint the right security solution for your company- Learn how to add 128- bit encryption and to authenticate your web site with VeriSign's FREE guide!

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:

    Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/

    This archive was generated by hypermail 2.0.0 : Fri Oct 19 2001 - 12:17:16 PDT