Bringing Design to Software ()
ed. by Terry Winograd (1946-)
This is a collection of articles and profiles of examples on the topic of software design. The collection begins with Mitch Kapor’s “A Software Design Manifesto”, from 1990. In this piece, Kapor called for creation of a discipline of software design, as opposed to the ad hoc approach of programmers and analysts. Naturally I am sympathetic to this call, as I see myself as a designer, rather than an analyst or programmer.
Winograd is involved with the new Association for Software Design, which offers this definition:
Software design is at the crossroads of all the computer disciplines: hardware and software engineering, programming, human factors research, ergonomics. It is the study of the interaction of human, machine, and the various interfaces – physical, sensory, psychological – that connect them.
The perspective of software design is to be human-centered, not machine- or information-centered. The point is to make the right software, to do the right thing for people who need or want something done by a computer. A moment’s thought should suffice to realize that too many systems are constructed without this perspective, and so fail to meet real needs.
Some of the articles are only slightly related to software design; they are intended to shed light on the question: What is design? One of the more useful articles is “Action-Centered Design”, by Peter Denning (George Mason University) and Pamela Dargan. Some extracts:
Approaches to Software Design …
Software design is concerned with the form and function of a software system. Two principal approaches are practiced. Software engineering, which dates to the 1960s, is based on the engineering tradition, where design is seen as a formal process of defining specifications and deriving a system from them. Human-centered design is more recent, dating to the late 1980s. In this approach, designers immerse themselves in the everyday routines and concerns of their customers. These approaches have complementary strengths and weaknesses. We believe that the two can be brought together into a new discipline: software architecture. The central practice of software architecture, action-centered design, produces maps that serve as blueprints, uniting system-oriented engineers and customer-oriented designers. …
The engineering design process operates from three assumptions:
1. The result of the design is a product (artifact, machine, or system)
2. The product is derived from specifications given by the customer. In principle, with enough knowledge and computing power, this derivation could be mechanized.
3. Once the customer and designer have agreed on the specifications, there is little need for contact between them until delivery. …
Human-centered design operates from three assumptions:
1. The result of a good design is a satisfied customer.
2. The process of design is a collaboration between designers and customers. The design evolves and adapts to their changing concerns, and the process produces a specification as an important byproduct.
3. The customer and designer are in constant communication during the entire process.
A New Interpretation of Design
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 people in performing those actions more effectively. The phrase domain of action is meant to be broad; it includes specialized domains, such as medicine, law, banking, and sports, as well as general domains such as work, career, entertainment, education, finance, law, family, health, world, dignity, and spirituality. Software engineers must reframe design drom a process of deriving a software system from specifications to a process of supporting standard practices in a domain, through software that enables more effective action.
The assessment of whether software is useful, reliable, and dependable is made by the people who act in a domain.
We asked designers of award-winning software packages, “What does it mean for a design to be intuitive and judged as complexity-reducing?” … All the designers said that they did not pay much attention to standard software-engineering methodology. Several said that the internal structure of their code is ugly and not well-modularized. When fixing bugs, they made patches; when the system got too patchy, they declared the next version and redesigned the software 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 distraction, and to perform new actions that previously they could only imagine. Customer satisfaction is not static: Customers change expectations, and software must evolve to track their shifting expectations. …
Pattern Matching as a Basis for a Discipline of Design
A discipline of software design should be capable of training its practitioners so that they can systematically fulfill promises to build and install software systems that are judged useful and dependable by their customers. …
… Architect Christopher Alexander says that the job of an architect is to give expression to the patterns in the use of space that permit the building’s occupants to carry out their daily actions effectively. He says that surprisingly few patterns are needed to describe and generate buildings – a dozen or two suffice for a home, and three or four dozen serve for for a typical office. …
The architect’s blueprint is a map (actually, an interrelated set of maps) that expresses the patterns and their relationships, and provides a common language across architect, builder, and client. … Although we do not yet have a formal method to construct maps [for software design and engineering], we do know what we would want from them. The maps would provide ways
– To convey the patterns of action of the domain in which the software will be used, in terms of its basic distinctions, repetitive processes, standards of assessment, strategies, tools, breakdowns, and driving concerns
– To connect the linguistic structure of the domain to the software structures that will support the patterns, and to guide software engineers in implementing those structures
– To provide a basis for measuring the effectiveness of the implemented system in practice. …
These maps should cover a number of basic patterns.
– A set of linguistic distinctions (verbs, nouns, jargon, etc.), around which people in the domain organize their actions (in personal finance, these distinctions include checks, ledgers, banks, bank accounts, bank statements, merchants, bills, fund transfers, deposits, credits, and interest).
– A set of speech acts by which domain participants declare and report states of affairs, initiate actions, signify completions, and coordinate with other people (in personal finance, these acts include pay, deposit, withdraw, transfer funds, reconciliation successful, prepare tax report, and cancel payment).
– A set of standard practices (recurrent actions, organizational processes, roles, standards of assessment) performed by members of the domain (in personal finance, these practices include paying monthly bills, reconciling the ledger, putting money into savings, preparing quarterly tax summaries, maintaining positive balances in accounts, earning good interest, having a minimum liquidity level, having a maximum debt level, and getting a credit rating).
– A set of ready-to-hand tools and equipment that people use to perform actions; a tool is ready to hand if the person using it does so with skill and without conscious thought (in personal finance, tese tools include pens, calculators, checkbooks, databases, tax forms, and monthly reports).
– A set of breakdowns, which are interruptions of standard practices and progress caused by tools breaking, people failing to to complete agreements, external circumstances, and so on (in personal finance, these breakdowns include errors in writing or coding checks, missing payments, discrepancies between ledger and bank statement, lost deposits, errors in credit reports, lost checks, inability to compile tax data, unresponsive customer-service departments, and broken modems).
– A set of ongoing concerns of the people in the domain – common misions, interests, and fears (in personal finance, tese concerns include a working banking system, good credit rating, liquidity, low debt, steady income, accurate tax data, good return on investment, and fear of tax audit).
This overall framework is sometimes called the ontology of the domain. Put simply, an ontology is a conceptual framework for interpreting the world in terms of recurrent actions. Building an ontology of the domain in which software will be used, representing it as a pattern language in a standard notation, and coordinating the work of builders are the central activities of a software architect.
The important aspects of action-centered design are its emphases on speech acts, on the use fo language, and on repetitive actions. … Speecha acts such as “I request”, “I promise”, “I have completed the task”, and “I am satisfied” are important because they are the motivating force for action. Without them, no task would be declared, initiated, or completed, and no one would know whether anyone else was satisfied. …
We propose an interpretation of design that is
– Focused primarily on satisfying the customer, rather than on satisfying a system’s specifications
– Grounded in a language-action perspective, rather than in a system-dataflow-network perspective
– Based on observations of concerns, breakdowns, standard practices, institutions, and recurring actions, and on production of means to connect those observations with software structures
This article is followed by a profile on business-process mapping. The profile is too short to be clear, and the one diagram appears not to match its caption. Following the references should help clarify the points.
In article 8, “The Designer’s Stance”, Bradley Hartfield states (p. 155): “In developing courses on design, it has struck me at times that the most you can do is to create a situation that allows students to learn for themselves. You can set up semistructured experiences, you can mentor them, you can help them to become reflective about what they’re doing. But you cannot tell them what to do and have them know it – that’s just not the nature of design.” Of course, this is exactly my position for all learning.
Two pages later, David Kelley makes a distinction between technical risk and design risk: “When you’re doing design, you’re making a decision to create a thing, and you don’t know who might say ‘That’s the wrong thing.’ It could be a marketing person, it could be the user. You have to make the leap first, and you can’t feel comfortable about the leap because it’s too uncertain. … People who are good inventors – good designers – don’t mind saying, “How about following this path, which doesn’t yet exist?” … “Successful designers just send out their vision to the world; and then, when somebody else builds on it, that’s okay. They’re not protective of their ideas because they’re so used to having ideas. A creative designer has an idea a minute. Publicizing an idea is a way to improve on the idea – someone else can build on it, expand it.”
In article 9, “Reflective Conversation with Materials”, Donald Schon says, “I use the term taste when I’m talking about the discriminatory appreciation of objects, with respect to, among other things, how well they are designed. A good designer has to have taste. It’s clear that having taste isn’t sufficient for being a good designer. But you do have to have it, in the sense that you’re able to make judgements of quality in many different ways. This discrimination needs to be roughly congruent with the more discriminating of the users for whom you are designing.”