A Discipline Of Software Design

Position Paper; Workshop on Software Design; 7-9 August 1992

Peter J. Denning; George Mason University; pjd@cs.gmu.edu

Pamela A. Dargan; The Mitre Corporation; dargan@pacific.mitre.org

July 24, 1992

Software engineering is not a discipline. Its practitioners cannot systematically make and fulfill promises to deliver software systems judged by their customers as usable and dependable, on time and fairly priced. The illusion that software engineers possess a discipline has produced the major breakdown called the software crisis.

The central claim explored here is that the standard engineering design process produces a fundamental blindness to the domains of action in which the customers of software systems live and work. The connection between measurable properties of the software and the satisfaction of those customers is, at best, tenuous. We propose a broader interpretation of design that is centered on observing the work processes of a community of customers in a domain and connecting those processes to supportive software technologies. The skill that a designer needs to have to observe work processes and begin making the connections is here called ontological mapping. This skill can be learned and is the basis of a discipline of software design.

Design as Deriving A System from Specifications

The dictionary lists no less than ten different senses of the verb "design". The primary meaning is "to conceive or execute a plan." Similarly, the noun means primarily "an arrangement or plan". Engineers use the term "design" in a specialized way that is consistent with this general definition.

Engineers say that design is the dominant paradigm of engineering. They intend "design" to describe a staged process that begins with a problem statement, constructs a statement of requirements and then system specifications, builds a system (or artifact), and tests the system to demonstrate that it meets the specifications within given cost constraints. Like other engineers, software engineers have used the engineering design process to construct software systems; in this case the process is called the software life cycle model, the most common varieties of which are the waterfall model and the spiral model. Unlike other engineers, software engineers cannot claim that the engineering design process has been successful. They have not developed a systematic method of producing software that is easy to use, is reliable, and is dependable: they have not developed a discipline of software production. This failure is called the "software crisis", a term that was first introduced nearly three decades ago.

Many explanations have been proposed to explain this anomaly. The most popular ones center on the notion that software is "complex" and violates the continuity laws that we are accustomed to in engineering -- changing of a single bit in a program can produce drastic changes of behavior. Software is seen as a "radical novelty" for which our customary engineering analogies are misleading. While these explanations seem to make people feel more comfortable with software that does not work well, none of them has produced a practical means of systematically producing usable, dependable software.

Three key assumptions underlie the engineering design process:

1. The result of the design is a product (artifact or system).
2. The product is derived from specifications; with enough knowledge and computing power, the derivation could in principle be mechanized.
3. Once the specifications have been given, there is little need for contact between the designers and the users.

The software crisis is usually seen as a breakdown in software or in methodology. When the crisis is seen instead as a breakdown of customer satisfaction, it is clear why the engineering design process produces the breakdown: there is little to connect the actions of designers with the concerns of customers. The interface between them is limited to the requirements and specifications documents.

Led by European software engineers, a new school has emerged called "user-centered design" that attempts to redress the shortcomings of "specification-oriented" or "product-centered" design. User-centered design attempts to understand the domain of work in which the user is acting with computers, and to design the computers to facilitate work. Anthropologists have played significant roles in this effort. Although, as we argue below, user-centered design is a significant step in a direction that may yield better software, it is not at a stage where its practitioners can systematically produce good software more efficiently than other software engineers. User-centered design may produce good designers through a process of apprenticeship, but it is not yet positioned to produce designers through systematic education and training.

Reframing Design as Altering Practices in a Domain of Action

A discipline of software design must train its practitioners to be skilled observers of the "domain of action" in which a particular community of people engage, so that the designers can produce software that assists in performing those actions more effectively. Engineers must reframe software design from "a process that derives a system from specifications" to "a process of altering standard practices in a domain for more effective performance by members of a community of actors in the domain."

We say this because the assessment of whether software is useful, reliable, or dependable is made by people in a community who are working together toward some common goal. By focusing on the system and its specifications, the traditional engineering process loses sight of the community, their common concerns, and their work; it cannot make a grounded assessment of quality because many of the factors influencing quality are not observable in the software itself. User-centered design, at least, does not lose sight of the community, but as presently constituted is not capable of systematically making grounded connections between user concerns and the structure of software.

Why is software design different from other engineering design fields such as architecture or bridge-building? Why haven't similar statements been made about those fields? Why do those fields appear as disciplines but not software engineering? The answers to these questions are not easy. The best answer we can give is, software is so intimately connected to the work processes of a domain, that shortcomings of the design show up immediately as (costly) interruptions of work.

What Led Us To This Claim

Starting from the observation that many software engineers are using object oriented design (OOD) as a way to frame the requirements analysis stage of the engineering design process, and object oriented programming (OOP) as an approach to the implementation, we asked a number of prominent software engineers this question: "What is the concern that drives people to find object-oriented programming so attractive?" (See Appendix.) Most see object-oriented programming as another fad, not a "silver bullet" that will end the software crisis. But most think that object-oriented programming appeals to some intuitive sense about how the program will be used and thereby is capable of reducing the apparent complexity of use of the program. We then asked, What does it mean for a design to be intuitive? When will a design be judged as one that reduces complexity?

To answer these questions, we asked, What software already exists that is widely acclaimed as intuitive and easy-to-use? What did its designers do? We chose a number of software packages for personal computers that have won several awards in the PC magazines for ease of use:

Quicken (by Intuit), a personal financial accounting system;
MeetingMaker (by On Technologies) and Synchronize (by Crosswind Technologies), systems for scheduling meetings and managing calendars in groups;
Topic (by Verity), a system for retrieval from texts; and
Macintosh user interface (by Apple).

We located and interviewed one of the chief designers of each to determine what that designer had done to win the accolades of the marketplace. There was a surprising level of unanimity in their answers:

Pick a domain of work in which a lot of people are involved and which is a constant source of breakdowns for them. (E.g., the designer of Quicken chose personal finance.)
Study the nature of the work people do in that domain. What actions do they perform repeatedly? What do they complain about most? What new actions would they like to perform next? (E.g., writing checks and balancing the checkbook; errors in arithmetic and discrepancies between bank statements and personal balance sheets; automatically generating reports for income tax purposes.)
Choose software functions that are obvious to anyone already practicing in the domain. Thus there is little to learn to get started because the the software merely helps them perform familiar actions. Make sure the functions also permit actions that most have wished they could do but could not do manually. (E.g., present images of checks that can be filled out; provide electronic payment; scan the database to produce a report of charitable contributions.)
Deploy prototypes in selected customer domains; observe how people react and what kinds of breakdowns they experience.
Because the customers frequently shift concerns, especially after they are seasoned users, it is necessary to provide many means of observing those concerns and taking them into account in the next version of the design. Thus there are many beta- test sites, individual follow-up, hot lines, highly attentive technical and customer support, suggestion boxes, bug advisories, and the like. It is of central importance to stay in communication with customers.
All the designers said they did not pay much attention to software engineering methodology. Several said that the internal structure of their code is ugly and is not well modularized. When fixing bugs they make patches; when the system gets too patchy, they declare the next version and reengineer it completely.

One way to summarize these findings is this: Software systems have customers. Quality means customer satisfaction. Customers are more likely to be satisfied by software that is transparent in their domain of work because it allows them to perform familiar actions without thought and allows them to perform new actions that previously they could only speculate about. Customer satisfaction is not static: customers change expectations and the software they use must be rapidly reconfigurable to track their shifting expectations.

Larger Systems

The software packages that we examined can be criticized as being "small systems"; much of the software crisis concerns "large systems". So we asked, What large systems exist that are widely acclaimed to be of high quality? We turned to the list of winners of ACM software systems awards:

1983 Unix
1984 Xerox Alto
1985 VisiCalc
1986 TeX
1987 Smalltalk
1988 System R and Ingres
1989 PostScript
1990 NLS
1991 TCP/IP

By examining the published papers of the authors of these systems, we came to similar conclusions. Each had a clear notion of who their customers were and what major breakdowns those customers faced. Each provided a system that facilitated familiar actions and resolved the breakdowns. Each allowed new actions that could only previously be speculated about. And each was designed to be rapidly changeable as the concerns and interests of the customers shifted.

Ontological Mapping As a Basis of a Discipline of Design

A discipline of software design would be capable of training its practitioners to systematically fulfill promises to build and install software systems that are judged useful and dependable by their customers. To accomplish this we need ultimately to

1. Understand the linguistic structure common to all domains of action, so that we can observe a particular domain for its basic distinctions, work processes, standard practices, standards of assessment, and driving concerns.

2. Know how to connect the linguistic structure of the domain to software structures that will assist in carrying out standard actions or in making standard assessments, and coordinate the implementation of those structures.

3. Know how to measure the productivity of people in the domain so that well-grounded assessments of their effectiveness in the presence of the software can be made.

Mapping is a powerful metaphor that connects these three elements. The purpose of a map is to allow its user to successfully navigate the territory. What is needed is a method of drawing maps of the linguistic structures of a domain and showing the linkage to software structures that assist those in the domain to carry out actions in each region of the territory. Although we do not yet have the means to construct such maps, we know what we would want from them. The same map should depict the domain structure (step 1), guide the software implementation (step 2), and help assess the outcome (step 3). The domain actors use it to navigate as they work (step 1); the software producers use it to navigate as they configure software systems (step 2); and managers or others it to guide their assessments (step 3).

Terry Winograd has argued that there is a strong analogy between architecture (constructing buildings) and the needed discipline of software design. The architect is a map-maker in the sense above. The architect must come to understand the ways in which the users of the building will work; this is represented as the blueprint. The same blueprint is used by the contractor to guide the construction of the building. The same blueprint is used later to make assessments of of the building after people move in, and to reconfigure portions of it if they demand changes.

In UNDERSTANDING COMPUTERS AND COGNITION, Terry Winograd and Fernando Flores discussed the framework in which design can take place. The common elements of every domain of action are:

A set of "linguistic distinctions" (verbs, nouns, jargon, etc) around which people in the domain organize their actions.
A set of "speech acts" -- statements whose utterance initiate actions and signify completions.
A set of "standard practices and institutions" -- recurrent actions, organizational processes, roles, and standards of assessment -- in which members of the domain engage.
A set of "tools and equipment" people use to perform actions. A tool is "ready-to-hand" if the person using it does so with skill and without thought.
Possible "breakdowns" -- interruptions of standard practices and progress caused by tools breaking, people failing to complete agreements, external circumstances, and the like.
A set of "ongoing concerns" of the people in the domain, for example their common mission, interests, or fears.

They call the framework outlined above the "ontology" of the domain. Building on this terminology, we propose "ontological mapping" as the skill that a software design must master. The architect's skill of creating a blueprint and using it to coordinate builders and later assessments is an example of this skill. The skill of ontological mapping can be learned and is the basis of a discipline of software design.

The designers of the prize-winning software packages and systems had all become observers of these phenomena in the particular domains in which they were designing.

To engineers it might seem strange that scientific principles can be deployed to develop systematic competence at producing customer satisfaction. In his recent book, MANAGING FOR THE FUTURE, Peter Drucker gives an example that illustrates this possibility. In the early 1900s, Frederick Taylor proposed scientific management as a means of observing and optimizing the motions that constituted work in a factory. Taylor had proposed methods of observation that worked with diverse factories. With his methods, managers were able to systematically organize manufacturing plants that produced significantly more, significantly faster, and significantly cheaper than earlier plants. At the onset of World War II, Hitler assessed (correctly) that Germany but not the US, had great expertise in optics, needed for accurate bombsights, and (incorrectly) that it would take the US five years to build the same expertise. This assessment led Hitler to declare war on the US, a deadly miscalculation: Six months later, having applied Taylor's principles to training workers how to assemble optical systems, the US was producing bombsights the equal of Germany's.

Such a discipline is possible for software production.

What We Have Done Here

We have proposed here that a new skill, which we call "ontological mapping", as the basis of a discipline of software design. This skill consists of these parts: the skill of observing the ontology of a domain, the skill of connecting linguistic structures in the ontology to software structures, the skill of coordinating the implementors, and the skill of assessing and reconfiguring after the software is placed in action. The one map can be used by the designer to aid those who work in the domain, those who implement, and those who assess. This skill can be seen in the examples of award-winning software packages and systems. The field of architecture illustrates that the skill can be learned.

We do not propose this interpretation as a final answer. It is a preliminary step. We offer it as an opening for a new direction in the investigation of software design.

APPENDIX

We asked several prominent computer scientists, "What is the fundamental concern that drives so many people to find object oriented programming appealing?"

Les Belady: "The desire to construct programs more out of components than out of statements."

Jim Horning: "OOP is a technology that has been gaining acceptance over the last 25 years (since Simula-67). Properly used, it is another tool in our arsenal for attacking complexity. So are modularity, abstraction, specification, etc. Just because none of them solves the entire problem doesn't mean that they aren't useful."

Jean Sammet: "I have been in this field a long time. I have seen numerous 'silver bullets' which were going to be the savior of the software field. Examples include structured programming, chief programmer teams, and numerous specific languages (e.g., COBOL, PL/I, Ada). There are lots of other examples of alleged 'silver bullets' ... Obviously none of these purported 'silver bullets' served in that role, or you wouldn't need to ask the question."

Bill Wulf: "In retrospect it's hard to believe, but there was comparable hype over the use of higher level languages, elimination of the 'goto', top-down design, etc. None of them was THE silver bullet, but the best of each has become woven into the fabric of the discipline. Taking the long view, a central problem of CS/SE [Computer Science / Software Engineering] is managing complexity, and certainly abstraction is a key tool for doing that. That aspect of OOP will certainly persist, but whether in the particular form seen in C++, for example, is problematical. Based on history, one would expect not -- simply because once the issues that OOP addresses are under control another set of problems will appear to be the most important and another type of mechanism will be needed."

Peter Wegner: "Object-oriented models determine abstractions that specify the domain-dependent behavior of real-world objects by their applicable operations. They determine the behavior of objects in a domain of discourse without any commitment to the execution of a particular task. Data is structured into encapsulated chunks whose behavior is determined by the operations that can act on the data. The focus on nouns rather than verbs as the basis for describing a domain of discourse makes it fundamentally declarative in the sense that it describes properties of a modeled world rather than particular computational processes."

Fred Brooks: "My answer, set forth in detail in 'No Silver Bullet', is that the next radical step forward in programming has to involve shifting the conceptual level at which one thinks and writes programs. The fundamental hope for OOP is that it permits one to move up a level by building a set of objects for the domain of discourse of the particular application area, hence allowing one to program within the intellectual context and using the elementary concepts of the particular application area. Most of today's programming languages are general- purpose, and work a level below this."

HTML markup by Brad Cox (bcox@gmu.edu) as part of the web at http://www.site.gmu.edu/~bcox/index.html