RE: [unrev-II] Simon's Paper

From: Gil Regev (
Date: Mon Oct 22 2001 - 09:19:21 PDT

  • Next message: Jack Park: "[unrev-II] Microsoft -- extending its tentacles"


    Thanks for the review. What is the title of the paper? Maybe it is on the
    Web already. Can you find it at this address (KMI tech. reports)?

      -----Original Message-----
      From: Eric Armstrong []
      Sent: vendredi, 19. octobre 2001 21:30
      To: unrev2
      Subject: [unrev-II] Simon's Paper

      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

            Choose from 1000s of job listings!

      Community email addresses:
        Post message:
        List owner:

      Shortcut URL to this page:

      Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.

    This archive was generated by hypermail 2.0.0 : Mon Oct 22 2001 - 09:07:25 PDT