Design of Design: Summary of Chapters 4-5

Chapter 4: Requirements, Sin, and Contracts

A Horror Story

• Talks about a Marine Corp General asking a Computer Designer and his/her group to create a helicopter that could carry weaponry, ammunition, warriors, etc, and still be able to "ferry" itself across the Atlantic Ocean.
• The Designer is horrified by the idea because flying across the Atlantic Ocean is not a helicopter's normal operating range. A helicopter has not yet been built that has the power to fly across the Atlantic Ocean.
• The Designer contemplated the idea that perhaps other designers have already come up with a solution to this problem. Maybe other more skilled designers know of a way to build a helicopter that can carry the amount of load necessary, as well as fly across the Atlantic.

Unfortunately, Not Unique

• Talks about who comes up with the requirements for the product, often it is jut a long list of requirements conjured up by architects and engineers who give their opinion based on their experience and instincts.
• In the end, some products turn into total disasters due to a large list of specifications and requirements.
• However, the Project Manager, who is in charge of the product development, often rejects requirements that seem impractical.

Fighting Requirements Bloat and Creep

• Requirement creeps often bombard developers with ideas either made by users or by internal inventors, however, their ideas are rejected with the best defense: scheduled urgency.
• The most effective way to avoid creeps is to appoint capable managers at the very begin of the process who will ensure the product is completed with at least the initial requirements.

Sin

• Suppose:
• Client is happy to pay the developers a fair price for their work.
• He has engaged an architect whose talents and professional skills he is eager to use to help serve the client's true interests.
• Contracting with a builder who does what he is supposed to do within budget, cost and on schedule
• Everyone is honest and truthful, and communication is excellent.
• Then: I would argue that
• A payment arrange will benefit the client and give them the most value per dollar.
• Design-build is the fastest way to get the project done.
• An explicit Spiral Model process will yield the product best suited to the client's needs.
• How can we explain the persistence of the WaterFall Model, when the greater fidelity of the Spiral and Co-Evolutionary models has been seen for more than a quarter century?
• The one-word answer is SIN: PRIDE, GREED, and SLOTH.

Contracts

• Talks about the importance of written agreements to clarify communication.

A Model for Contracting

• Normal Building Design Process:
• Client develops a program for the building.
• He contracts with an architect.
• Architect elicits from the client, users, and other stakeholders a more complete program.
• Architect builds a conceptual design that approximates budgets, reconciliation of program, schedule and code.
• Architect performs design development, often by drawing or models.
• Clients uses drawing to enter into a fixed-price contract for the product.
• Often there are drawbacks. Building projects with
• Close trusted relationships between client, architect and contractor,
• Well-understood design challenges, or
• A pressing hurry, justifying higher risks,
• often hinders the normal process of the design-build process.

Chapter 5: What are Better Design Process Models?

Why a Dominant Model?

• Talks about how models are defined by simplified abstractions of reality. A person could easily argue that a dominant model is a fool's errand because it emphasizes some aspects and omits others.
• The author disagrees saying that the Waterfall Model convinces him that communication is necessary and the nature of academic instruction mean that there will be a dominant model of the design process.

The Co-Evolution Model

• Maher, Poon, and Boulanger proposed a formal model, Co-Evolution Model.
• Model is design has Problem 1 --> Prototype 1 --> Problem 2 --> Prototype 2 -->Problem 3 --> Prototype 3 --> and so on.
• This model emphasizes progressive discovery and formulation of requirements.
• Whirlgig Model
• This proposed model, is complex to understand, much less memorize, and facile use in discussion was used for cycles and epicycles.

Raymond's Bazaar Model

• How It Works
• Creating community sees a need, develops a module to meet it, and offers it to his peers as a gift. This type of module in integrated in the Linux community. It helps facilitate modularity in structure.
• Some people write new modules and fix bugs.
• Strengths
• Raymond argues that the system products produced by this process are technically superior to those produced by the cathedral process.
• When Does the Bazaar Work?
• Evolutionary model which means large system grown by adding components which fulfills a requirement.
• The economy works for people who are being fed, that means the software gifts to the community are by-products of other people's work that produces revenue to pay the builders-donors.
• A key to all design processes is the discovery of the users' needs, wants, and criteria.
• Open Source process can not be used to build a new national air-traffic controls system, which is why a cathedral process is still necessary.

Boehm's Spiral Model

• Model proposed for the building of software.
• Spiral shape suggest progress.
• Denning and Dargan say that the Spiral Model is an improvement, but it is centered around the designer and the product rather than the user and action.
• Brooks believes the way forward is to embrace and develop using this model because this model accommodated the progressive discovery of requirements, but did not emphasize on it or on contracting points.

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.

Summary Arguments is copied verbatim from the book, Design of Design: Essays from a Computer Scientist by Frederick P. Brooks Jr.