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

the basic message: computational systems of the future

will be complex, embedded systems

need to be open and not closed

need to evolve

SimCity allows users to build a city within the framework, object sets, and constraints provided

apart from the SimCity Urban Renewal Kit (SCURK)-an add-on module to increase user control-it is a closed system

example: too much crime

- solution supported: build more police stations (fight crime)

- solution not supported: increase social services, improve education (prevent crime)

claim: SimCity fails when applied to "real" city-planning problems (such as the Boulder HOP design)

challenge: build a Simcity-like environment which is open and can evolve

Dawkins - "The Blind Watchmaker": big-step reductionism cannot work as an explanation of mechanism; we can't explain a complex thing as originating in a single step

Simon - "The Sciences of the Artificial": complex systems evolve faster if they can build on stable subsystems

Petroski - "To Engineer Is Human": the role of failure in successful design

Brooks - "No Silver Bullet": successful software gets changed, because it offers the possibility to evolve

Polanyi - "The Tacit Dimension": knowledge is tacit ----> we know more than we can say

John Archibald Wheeler: "our whole problem is to make the mistakes as fast as possible" (foreword to the book) - breakdowns as opportunities

criticism of our conjectures is of decisive importance and all of our knowledge grows only through the correcting of our mistake- critiquing systems

there are all kinds of sources of our knowledge but none has authority - symmetry of ignorance and mutual competency

the advance of knowledge consists in the modification of earlier knowledge - evolution

from medium to artifacts

from material to architecture

from intrinsic properties to goals, objectives, and use contexts

examples:

- 500 hammer story (in 1867) - the main issue is not the material or the medium, but the different task structures

- "software" engineering (we emphasize the medium/material)

- in other domains: we do not speak of concrete or steel engineering, but of civil engineering, electrical engineering, bridges, office buildings

the most critical software problem is the cost of maintenance and evolution

- empirical studies of software costs: two-thirds of the costs of a large system occur after the system is delivered

- claim: much of this cost is due to the fact that a considerable amount of essential information (such as design rationale) is lost during development and must be reconstructed by the designers who maintain and evolve the system.

make enhancements and evolution "first class" activities in the lifetime of an artifact

- accept the reality of change

- acknowledge increased up-front costs (cognitive and economics)

support the construction and evolution of domains (program families)

empirical fact: reuse is most successful within domains

not just objects, but:

- case libraries (different granularity)

- critiquing (accumulated "wisdom" of a community of practice

- specification component - partial characterization of a situation model

- simulation - to understand the behavior

- argumentation - to explore the rationale behind the artifact

SER model is a process model to seed, evolve and reseed an economy of educational knowledge

the seeding, evolutionary growth, and reseeding process model

group memories

- collection of shared information repositories containing a cumulative record of rationale, solution components, and information about prior activities in the same and related projects

- how does information get into the memory and how does it accumulate?- "who is the beneficiary and who has to do the work"

- how is information in the memory made available to the individual designer and contextualized to specific tasks?

"back-talk" of a partially constructed, externalized artifact

- many situations are mute - they do not talk back

- mechanisms to increase the "back-talk": critiquing, simulation, testing

- the "back-talk" needs to be addressed to the users, not to the developers (because they experience breakdowns

Seeding, Evolutionary Growth and Reseeding

seeding

- seed a domain-specific DODE using the domain-independent, multi-faceted architecture

- provide representations for mutual learning and understanding between the involved stakeholders

- make the seed useful and usable enough that it is used by domain workers

evolutionary growth

- co-evolution between individual artifacts and the DODE

- learning on demand and end-user modifiability complement each other

reseeding

- formalize, generalize, structure

- a social and technical challenge

success example of the SER model:

- development of operating systems

- "communities of practice"

evolution at the conceptual framework level

- end-user modifiable DODEs

- example: multifaceted, domain-independent architecture

evolution of the domain

- evolution was driven by new needs and expectations of users as well as new technology

- example: computer network design

evolution of individual artifacts

- long-term, indirect collaboration

- design rationale

- example: the computer network at CU Boulder

co-evolution

- problem framing and problem solving (specification and implementation)

- individual artifact and generic, domain-oriented design environment

Ontogeny = development of an individual organism

- a design can be described and tested against the knowledge contained in the design environment

- breakdowns lead to new insights

- enhancements are the major part of real software systems and should be done by the application domain workers

Phylogeny = history of a species

- background knowledge can never be completely articulated

- design knowledge is tacit

- design practice changes with time

Co-Evolution: ontogenic and phylogenic design activities are dependent on each other

Examples:

- ontogenic: campus network at CU Boulder

- phylogenic: a domain-oriented design environment for computer network design

the evolutionary metaphor must be approached with caution because

- there are vast differences between the world of the made and the world of the born

- one is the result of purposeful human activity, the other the outcome of a random natural process.

does software develop according to the "punctuated equilibrium" theory?

- if yes, what causes the periods of increased change (subroutines, object-oriented programming, the world-wide web)?

End-User Computing

competent practitioners usually know more than they can say - tacit knowledge is triggered by situations, by breakdowns

end-users: are the owners of problems, have the domain knowledge, are the users of computational artifacts

end-users:

- regard computers as useful machines capable of helping them work more productively, creatively, and with greater pleasure

- like computers because they get their work done

computer scientist / programmers

- find computer themselves intrinsically interesting

- like computers because they get to program

ultimate goal/belief: end-users will use, tailor, extend and create their own computational artifacts when they have domain-oriented design environments

community of users will develop: power users, local developers, gardeners

Modifier (EUM component of Janus)

- mechanisms to add new objects and new behavior by the domain designer

Gimme

- web-based group memory system

- supports communication between all stakeholders

Expectation Agents (with NYNEX, UC Irvine)

- support communication between developers and end-users

- observe actions of end-users and compare them to descriptions of the intended use

Chart 'n Art (self-disclosure): a gentle transition from direct manipulation interfaces to end-user programming

Visual Agent Talk (VAT)

- representations of conditions, actions and rules as graphical objects

- interface support (drag and drop) for end-user programming

Remote Explorium: evolution by a community of practice over the WWW

a fundamental principle: "Complex systems will evolve from simple systems much more rapidly if there are stable intermediate forms than if there are not." (Simon)

experience with software reuse in the past:

- reuse does not work as expected

- reuse is not for free

- reuse requires support tools (e.g., for capturing design rationale)

- object-oriented design may be necessary, but is not sufficient

reuse is not only a technical problem:

- design for reuse --> increases up-front costs

- reuse requires an organizational commitment

empirical study: McGuckin Hardware in Boulder, Colorado - more than 350,000 different line items

- problem framing and problem solving are intertwined (from heat generation to heat containment)

- to determine the adequacy/relevance of a found object requires "simulation of use situation" (the plumber story)

empirical finding: "computer systems have the same functionality as McGuckin, but are operated like K-Mart"

claim: to make an "economy of educational objects" a success, more is required than creating objects and depositing them in a globally accessible information repository