Wisdom is not the product of schooling but the lifelong attempt to acquire it. - Albert Einstein

natural science: "how things are"

- knowledge about natural objects and phenomena

- primary interest: analysis

- examples: physics, chemistry

sciences of the artificial: "how things might be (and ought to be in order to attain goals and to function)"

- knowledge about artificial objects and phenomena

- primary interest: synthesis

- artificial things are as they are only because of a system's being molded, by goals and purposes, to the environment in which it lives

- examples: engineering, medicine, business, architecture, painting

Definition of "artificial": human-made as opposed to natural

questions: where does mathematics / computer science / biology belong too?

claims by Simon:

- the world in which we live in today is much more a human-made, or artificial, world than it is a natural world

- a plowed field is no more part of nature than an asphalted street - and no less

Alan Kay (Scientific America, Sept 84, p 57)

"molecular biology has the advantage of studying a system already put together and working; for the composer of software the computer is like a bottle of atoms waiting to be shaped by an architecture he must invent and then impress from the outside"

Definition:

Everyone designs who devise courses of action aimed at changing existing situations into preferred ones. The intellectual activity that produces material artifacts is no different fundamentally from the one that prescribes remedies for a sick patient or the one that devises a new sales plan for a company or a social welfare policy for a state (Simon, "Sciences of the Artificial", p 130)

examples: architects, doctors, managers, politicians, teachers, ......

generic design - does it exist?

- design as an activity has a distinct conceptual and cognitive realization from non-design activities

- it can be abstracted away from the particulars of the knowledge base of a specific task or discipline and studied in its own right

there is no definitive formulation of a wicked problem. For any given tame problem, an exhaustive formulation can be stated containing all the information the problem-solver needs for understanding and solving the problem.

they have no stopping rule. In tame problems, problem solvers know when they have done the job. Problem solvers terminate work on a wicked problem, not for reasons inherent in the 'logic' of the problem.

solutions to wicked problems are not "true-or-false", but "good-or-bad"

every wicked problem is essentially unique

the aim is not to find the truth, but to improve some characteristics of the world where people live

biology is the study of complicated things that give the appearance of having been designed for a purpose

physics is the study of simple things that do not tempt us to invoke design

treat complex human-made artifacts (e.g., computers, airliners, cars, books) as biological objects

the behavior of physical, nonbiological objects is so simple that it is feasible to use existing mathematical language to describe it

a complex thing is something whose constituent parts are arranged in a way that it is unlikely to have arisen by chance alone

things evolve in response to some kind of selective force

simple scheme of evolution:

- generate - produce variety (e.g. genetic mutation)

- test - to evaluate the newly generated forms (e.g. natural selection)

problems with evolution:

- is myopic

- reaches local maxima (instead of global ones)

- moving away from a local maxima implies: going across a valley

Design different from Evolution:

- guided

- there is a goal (question: can we design without a final goal in mind?)

- one can look back over a design and "clean it up"

- one can examine failures and see what went wrong

- faster than evolution (guidance, remembering previous successes and failures)

Is Design the same as Evolution?

- "installed base" problem ("qwerty" typewriter, English measurement system, Fortran/Cobol, .....)

- standards

- knowledge is cumulative

claim: to design a complex structure, one powerful technique is to discover viable ways of decomposing it into semi-independent components corresponding to its many functional parts. The design of each component can then be carried out with some degree of independence of the design of others, since each will affect the others largely through its function and independently of the details of the mechanisms that accomplish the function.

examples:

- functional programming

- object-oriented programming

- rule-based systems

- nearly decomposable systems

Simon:

in oil painting every new spot of pigment laid on the canvas creates some kind of pattern that provides a continuing source of new ideas to the painter. The painting process is a process of cyclical interaction between the painter and canvas in which current goals lead to new applications of paint, while the gradually changing pattern suggests new goals.

Computer Science Technology Board:

system requirements are not so much analytically specified as they are collaboratively evolved through an iterative process of consultation between end-users and software developers

Rittel:

one cannot understand a problem without having a concept of the solution in mind

one cannot gather information meaningfully unless one has understood the problem but one cannot understand the problem without information about it

going to the moon: a "complex" problem along one dimension; sources for success:

- exceedingly cooperative environment

- employing a single new organization

- single, highly operational goal

the American Constitution:

"the founding fathers did not postulate a new man to be produced by new institutions but accepted as one of their design constraints the psychological characteristics of men and women as they knew them, their selfishness as well as their common sense" (Simon)

1991: final design competition

1995: construction finished

requirement: 15 years without major modifications

question: a library in the year 2010? - books, CD ROM, .... ---> we are not only designing for a given context: we construct the context

client: city of Denver ---> committee (old librarian, techi, ...)

who owns the problem??

- client(s), designers, customers, specialist, ......

- architect, structural engineer, contractor, bricklayer, ......

1st Generation (before 1970):

- directionality and causality

- separation of analysis from synthesis

- major drawback: perceived by the designers as being unnatural; does not correspond to actual design practice

2nd Generation in the early 70'es:

- participation - expertise in design is distributed among all participants

- argumentation - various positions on each issue

- major drawback: insisting on total participation, neglecting expertise possessed by a well-informed and skilled designer

3rd Generation (in the late 70'es):

- inspired by Popper: the role of the designer is to make expert design conjectures

- these conjectures must be open to refutation and rejection by the people for whom they are made (---> end-user modifiability)

goals:

- bring task to the forefront

- analysis of work products

- goal sharing (for agents, critics, task-based indexing)

- information delivery

- learning on demand

- external simplicity through internal complexity

theory:

- collaborative problem solving

- distributed cognition

- integration of problem framing and problem solving

- reflection-in-action

- design-in-use

- situational awareness

- computational environments as "living" entities

users:

- skilled domain workers

- stakeholders with different interest and different background knowledge

General Programming Environments, e.g., Lisp, ... -----> limited reuse

Object-Oriented Design, e.g., Smalltalk, Clos, C++, .

-----> lack of domain-orientation

Domain-Oriented Construction Kits, e.g., Pinball, Music Construction Kits

-----> no feedback about quality of artifact

Constructive Design Environments>, e.g., critics, explanations

----> design is an argumentative process

Integrated Design Environments, e.g., combining construction and argumentation ----> lack of shared context

Multifaceted Architecture ----> limited evolution

End-User Modifiable Design Environments

user interface design - Framer

floor plan design for kitchens - Janus, KID

graphics software - Explainer

computer network design - Network, Pronet

water management - Cadswes (with CU research center)

Cobol programming and service provisioning - GRACE (with NYNEX)

voice dialog design - VDDE (with USWest)

lunar habitat design - HERMES (with NASA)

graphic arts, information design, information visualization - Schemechart, Chart 'n' Art

multi-media design environment - eMMa (with SRA)

increase on the system's side

- domain-orientation

- construction

- specification

- embedded communication and history

- incremental formalization

increase on the user's side

- "back-talk" of the situation (critics, simulation)

- specification support through the argumentation component

- making argumentation serve design (providing arguments behind critiquing messages)

- access and delivery of cases (catalog examples) relevant to the task at hand

technology is becoming powerful enough to get out of the way (bring tasks to the forefront)

achieve external "simplicity" with internal complexity (human problem-domain interaction)

information technology is a generic activity (ubiquitous computing, clay) --->but: a "product / system" will not exist until it enters a specific situation, where all stakeholders will mold it to the work of a community of practice

information technology as a distinct category of products will become invisible ---> it will dissolve into the work itself

DODEs support "human problem domain communication"

DODEs are instrumental versions of systems that are simultaneously user-directed and computationally supportive

critiquing

- breakdown as opportunities

- supports contextualized learning on demand

- makes argumentation serve design

seeds need to be functional enough that they are used by skilled domain designers in their work

sociological structure of communities of practice with power users and local developers

current limitation of DODEs:

- limited success models - specifically lack of experience with evolutionary growth in naturalistic settings

- tool mastery burden

research issue for DODEs

- design rationale

- case-based reasoning

- integrated artifact memories

- multi-user DODEs

- evolutionary growth through use

- new contracts between stakeholders

challenges

- the question is how - not why?

- how large or small, general or specific should a domain be?

- cost-effectiveness: powerful substrates are needed