5. What Are Better Design Process Models?
Boehm’s Spiral Model
Boehm [1988]. Boehm © 1988 IEEE.
It is widely accepted that creative design is not a matter of first fixing the problem and then searching for a satisfactory solution concept; instead it seems more to be a matter of developing and refining together both the formulation of the problem and ideas for its solution, with constant iteration of analysis, synthesis and evaluation processes between the two “spaces”—problem and solution.
NIGEL CROSS AND KEES DORST [1999],
“CO-EVOLUTION OF PROBLEM AND
SOLUTION SPACES IN CREATIVE DESIGN”
Why a Dominant Model?
Both practice and the education of designers now cry for answers:
• If the Rational Model is really wrong,
• If having a wrong model really matters, and
• If there are deep reasons for the long persistence of the wrong model,
then what are better models that
• Emphasize the progressive discovery and evolution of design requirements,
• Are memorably visualized so that they can be readily taught and readily understood by team and stakeholders, and
• Still facilitate contracting among fallen humans?
All models are by definition simplified abstractions of reality. Hence there can be many useful models of a design’s life-cycle progression, each emphasizing some aspects and omitting others. Mike Pique made a video that dramatically highlighted this point by showing some 40 different computer graphics models of the protein bovine superoxide dismutase: stick models, ribbon models, solid models, action models, and others.1
One could therefore cogently argue that seeking a dominant model for the design process is a fool’s errand. Why not let 100 models bloom? Each will add illumination.
I strongly disagree. The ubiquity of the Waterfall Model in software engineering, despite the many criticisms and the damage done by its oversimplification, convince me that the need to communicate and the nature of academic instruction mean that there will be a dominant model of the design process. Thus the pressing need is to substitute a less misleading model, not merely to augment present practice with a better model. Indeed, in the wider field of design, I see Simon’s problem-solving model as having occasioned a lot of wasted effort in blind alleys by people trying to understand and improve design.
The Co-Evolution Model
Maher, Poon, and Boulanger proposed a formal model which I find helpful, the Co-Evolution Model.2,3 Cross and Dorst describe this model as follows:
It seems that creative design is not a matter of first fixing the problem and then searching for a satisfactory solution concept. Creative design seems more to be a matter of developing and refining together both the formulation of a problem and ideas for a solution, with constant iteration of analysis, synthesis and evaluation processes between the two notional design ‘spaces’—problem space and solution space. The model of creative design proposed by Maher et al. [1996] is based on such a ‘co-evolution’ of the problem space and the solution space in the design process: the problem space and the solution space co-evolve together, with interchange of information between the two spaces [Figure 5-1].4
Figure 5-1 Maher, Poon, and Boulanger’s Co-Evolution Model of design (Maher [1996])
Evolution is used loosely here. The model is evolutionary in that both the understanding of the problem and the development of the solution are incrementally generated and incrementally evaluated.
Philosophers of technology have recently wrestled at length with the question of how well the process of human innovation is modeled by biological evolution. Ziman [2000], a work of many chapters by authors from many disciplines, gives a good summary of the state of thinking on the topic by philosophers and others as of 2000.5 It sets forth arguments both that biological evolution is a good model, involving random generation and natural selection, and that it is not, because innovation is guided by purposeful design (the authors presume that evolution is not).
The Co-Evolution Model certainly emphasizes the progressive discovery and formulation of requirements. Its visual representation is memorable. It isn’t very comprehensive: it doesn’t pretend to include all aspects of the design-build-test-field-maintain-extend process. Moreover, the geometric image does not suggest a convergent process. So far as I can tell, the model has not yet had a lot of subsequent development and, as originally formulated, contained no milestones and contracting points. Although the model is attractive and better than the Rational Model, I don’t think it is sufficient.
Whirligig Model
Yet it is important not to go overboard. Some of the proposed models, though rich, are so complex as to defy understanding, much less memorization and facile use in discussion. An example is Hickling’s Whirligig Model, with cycles and epicycles.6
Raymond’s Bazaar Model
Raymond in his brilliant The Cathedral and the Bazaar [2001] argues that the whole notion of a cathedral-like design process has been outmoded by the Open Source, “bazaar,” process that has richly and effectively led to the development of Linux, a marvelously functional and robust operating system. His arguments are powerful and crisply formulated. He argues that the Open Source process can be the most effective way to develop all sorts of application programs, as well as operating systems. He illustrates with Fetchmail, his own creation.7
How It Works
As Raymond describes the bazaar process, a member of the using/creating community sees a need, develops a module to meet it, and offers it to his peers as a gift. Integration of the module is, in the Linux community, greatly facilitated by the modularity of the Linux structure, especially its pipes and filters mechanisms. The same process works for the repair of bugs. Someone detects a bug in a module he is using, finds it, fixes it so he can get his own work done, and then offers the fix as a gift to the community.
Clearly people write new modules and fix bugs so they can do their own work. Why do they give away the results, when the necessary testing, documentation, and publication demand substantial extra work?8 Raymond’s answer, which rings true to me, is that the incentive and the reward is prestige.9
Often multiple modules or multiple fixes for the same bug are offered to the community. Raymond argues that a market mechanism (even among free goods) is at work. The better tool, the better fix, wins the more widespread acceptance, and its author proportionately wins more prestige.
So the bazaar is populated with many “vendors” offering their digital wares electronically. Many buyers, with their votes, pay recompense in a prestige communicated electronically throughout a worldwide community.
Strengths
What a wonder is this gift-prestige culture! How unlike crass work-for-money, claim-my-intellectual-property-rights! What a new model for other societal activities!
Moreover, Raymond cogently argues, the system products produced by the bazaar process are in general technically superior to those produced by the cathedral process. First, the market mechanism selects, in evolutionary fashion, the best-designed modules. Second, subjecting a new module simultaneously to hundreds of testers smokes out the bugs sooner, yielding a more robust product. Third, bugs are fixed better, because of market selection among fixes.
Thus the bazaar process is put forward as a totally new model both for product creation and for collaboration among electronically coupled, asynchronously communicating, mutually unacquainted teams.
I strongly urge all of my readers to read Raymond—not just the widely circulated title essay, but the other chapters in the book. There is much truth, much insight, and much wisdom there.
When Does the Bazaar Work?
Nevertheless, I would make six independent short observations about the Open Source process. This is in lieu of a protracted discussion, since I have no personal experience using it.
• The Bazaar is indeed an evolutionary model. The larger system is grown by adding components, each of which meets a need (a requirement, if you will) discovered by the user-designer.
• The gift-prestige economy works for people who are being otherwise fed; that is, the software gifts to the community are by-products of other work products that produce the revenue to pay the builders-donors.
• Since many of the products so made are indeed by-products, there have been more tools than applications. The results are not always quite polished or quite debugged—they only have to be good enough for the purpose of the builder. The “market” selection is in fact the quality control.
• Despite much that has been written about the “openness” and the “freedom” of the Open Source process, the total Linux edifice is hardly a random pile of idiosyncratic pieces—Linus Torvalds has been an overarching intellectual force for conceptual integrity. Moreover, for Linux a functional specification already existed: UNIX. Of equal importance, an overall system design existed.
• A key to all design processes is the discovery of the users’ needs, wants, and criteria. The conspicuous success of the bazaar process in the Linux community seems to me to derive directly from the fact that the builders are also the users. Their requirements flow from themselves and their work. Their desiderata, criteria, and taste come unbidden from their own experience. The whole requirements determination is implicit, hence skipped. I strongly doubt if Open Source works as well when the builders are not themselves users and have only secondhand knowledge of the users’ needs.
• Hence there is still a need for cathedral processes, carefully architected, tightly controlled, and meticulously tested. Would you use the Open Source process to build the new national air-traffic control system?10
Boehm’s Spiral Model
Barry Boehm proposed in 1988 the Spiral Model for the building of software.11 The chapter frontispiece shows the model as originally proposed. The spiral shape certainly suggests progress. It associates successive repetitions of the same activity. The geometric shape is easily understood and memorable. The model emphasizes prototyping, starting with user-interface prototypes and user testing long before an operational prototype is possible.
The model has had wide acceptance; it is even permitted as a substitute for the Waterfall Model in U.S. Department of Defense procurements.12 It has also had some development.
Denning and Dargan [1996] have criticized the Spiral Model: “[It is an improvement], but it is still designer and product centered, rather than user and action centered.”13 They go on to propose a rather informal action-centered design process which properly gives increased attention to the users and the use models. I recommend their thoughtful paper.
Nevertheless, since a development model is principally used by developers, I believe having it designer-centered is entirely appropriate. Moreover, their process approach does not address the need for a memorable geometric model or for a basis for arriving at contracts. With Boehm and against Denning and Dargan, I advocate frequent but not continuous interaction with representative users, with successive prototypes as the vehicles.
As originally proposed, the Spiral Model accommodated, but did not emphasize, the progressive discovery of requirements, nor did it emphasize contracting points.
I strongly believe the way forward is to embrace and develop the Spiral Model. I would suggest punctuating the spiral with explicit contracting points, augmented with clear specification of what can be contracted, with what certainties, and with what explicit distribution of risk. Risk management is the focus of much of Boehm’s later work.14
Design Process Models: The Summary Argument of Chapters 2–5
• A formal design process model is needed, to help organize design work, to aid communication in and about projects, and for teaching.
• Having a visual, geometric representation of a design process model is crucial, for designers are spatial thinkers. They will most easily learn, think about, share, and talk in terms of a model with a clear geometric picture.
• The Rational Model of design occurs naturally to engineers. Indeed, it has been independently and formally set forth several times: for example, by Simon, by Pahl and Beitz, and by Royce.
• The linear, step-by-step Rational Model is highly misleading. It does not accurately reflect what real designers do, or what the best design thinkers identify as the essence of the design process.
• The bad model matters. It has led to the too-early binding of requirements, leading in turn to bloated products and schedule/budget/performance disasters.
• The Rational Model has persisted in practice despite its inadequacies and plenty of cogent critiques. This is because of its seductive logical simplicity, and because builders and clients need “contracts.”
• Several alternative process models have been proposed. I find Boehm’s Spiral Model the most promising. We need to keep developing it.
Notes and References
1. Pique [1982], What Does a Protein Look Like?
2. Maher [1996], “Formalising design exploration as co-evolution.”
3. Maher [2003], “Co-evolution as a computational and cognitive model of design.”
4. Cross and Dorst [1999], “Co-evolution of problem and solution spaces in creative design”; Dorst and Cross [2001], “Creativity in the design process.”
5. Ziman [2000], Technological Innovation as an Evolutionary Process.
6. Hickling [1982], “Beyond a linear iterative process?”
7. Raymond [2001], The Cathedral and the Bazaar. I suspect the “cathedral” he has in mind is suggested by the frontispiece of Chapter 4 of The Mythical Man-Month.
8. Brooks [1975], The Mythical Man-Month, Chapter 2.
9. Raymond [2001], “The golden cauldron.”
10. Richard P. Case wisely remarks,
Maybe we should distinguish the “anybody can change it” and “anybody can see it” aspects of open-source design. If anybody can change it, nobody can do a confident analysis when something (even fatal) goes wrong, or give any kind of assurance that it has been fixed so that it won’t happen again. Secrecy is a different matter. If only a few minds have access to the actual design, it is less likely that flaws will be discovered early and that alternate concepts will be developed and evaluated (personal communication [2009]).
11. Boehm [1988], “A spiral model of software development and enhancement.”
12. The Department of Defense has since wisely adopted industry software development standards IEEE/EIA 12207.0, IEEE/EIA 12207.1, and IEEE/EIA 12207.2. These permit spiral models.
13. Denning and Dargan [1996], “Action-centered design,” 110.
14. Selby [2007], Software Engineering: Barry W. Boehm’s Lifetime Contributions to Software Development, Management, and Research, collects Boehm’s most important papers on risk into Chapter 5.