Eric,
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)?
http://kmi.open.ac.uk/publications/techreports-text.cfm
Gil
-----Original Message-----
From: Eric Armstrong [mailto:eric.armstrong@sun.com]
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.
Simon:
Perhaps you can make it available on the web
somewhere, or send it to folks who request it.
Notes
-----
* "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
further.
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
material.
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
detail
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
projects.)
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.
Conclusion
-----------
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: 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:
http://www.onelist.com/community/unrev-II
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