Design of Design - Summary of Chapters 8 - 10

Chapter 8: Rationalism Versus Empiricism in Design
Rationalism versus Empiricism

• Can one person alone design a complex object correctly by a sufficient thought?
• The answer can be given in two way depending perspective.
• Empiricists would believe one person cannot.
• Rationalists would believe one person can.
• These two perspectives can be broken down into thoughts deeper.
• Empiricist believes that man is inherently flawed and could repeatedly have an urge to do things wrong.
• Rationalists would believe man is inherently sound. Man can make mistakes, but can also fix these mistakes with education and maturity.

Software Design

• Rationalists would believe that computer programs are mathematical objects fashioned in abstraction and made correct by proof.
• One should design software to be correct, and then prove the design is correct.
• Empiricists would believe that humans will inevitably make mistakes. 
• Firm faith in fallibility can be a good thing because it allows for important decisions to take place early on in the project, for instance, design, early prototypes, early user testing, iterative incremental implementation, testing on a rich bank of test cases, and regression testing after changes.

I Am a Dyed-in-the-Wool-Empiricist

• Brooks mentions that only twice in his life has he written a program that worked correctly the first time and did what he wanted it to do.
• However, Brooks desk-checked the 1,500 line code meticulously before running the program for the first time.
• This experience is an existence proof for the possibility of rational design for correctness. However with real people, it is hard to maintain the motivation of repeatedly checking code.
• Designing program in a correct way, to show that operating system are designed and implemented correctly, people use formal proof methods to prove this.
• Kernel is probably as far as the correctness proof techniques should be applied.
• Harlan Mills and his colleagues developed a "cleanroom" technique for correctness-proving. People are divided into teams, the design group explains why their design is correct, while other challenge the argument and assumptions.
• "Formal proof of correctness is usually infeasible; abandoning all effort of systematic verification is dangerous..." (Brooks, 108).

Rationalism, Empiricism, and Correctness in Other Design Domains

• Designers have only attempted to prove correctness by formal method in software engineering.
• Software design in which no material is involved is like organization design.
• People now do rigorous analysis on mechanical parts, from stress, vibration, to acoustic analyses.
• Real-time videotaped walk-through can help guide architects and clients through simulated use scenarios of buildings/other developed objects.
• With this extensive empirical analyses comes greater iteration in the design process.
• Can one person alone design a complex object correctly with a sufficient thought alone?
• The answer is NO, testing and iteration are in practice necessary.

Chapter 9: User Models -- Better Wrong than Vague
Explicit User and Use Models

• Experience designers start by writing everything they know about the user, purpose of use, and mode of use so far. Designers who are wise also write down things that they don't know but can assume about the user.

Really?

• Not very many designers want to do that extra work before starting on a design. However, it is a necessary practice, and doing so will improve the designer's design practice.

Team Design

• All designers have some visual idea in their minds of how the user will be able to use this object/device. 
• The exercise of having the same user model and the same use model is rare because the members of the team usually believe that they share a common set of assumptions. 
• However, assumptions can be wrong sometimes, then differing models can yield to inconsistent designs in the team.
• Complex Designs.
• With the growth of complexity, the need for explicit use models increases. 
• For example, a shovel can be used to move snow, grain, coal, etc. For that reason, it is important to explicitly state what it's needed for.

What If the Facts Are Not Available?

• Most designers are confronted with the fact that they don't know much about the object when they start creating a use model.
• Example: Product that routes and schedules school buses. You have to look at time constraints, number of buses, number of drivers, geographic distribution of pupils, etc. 
• "As the questions get harder, the answers get vaguer" (Brooks, 116).

Guess!

• Once a designer has move beyond questions that can be answered, he should guess a set of attributes in order to develop the user and use models.
• Writing down the values can create something concrete which can then be easily criticized and debated on.
• Most important questions
• Which assumptions matter?
• How much?
• Assumptions always remain debatable in the end.

Better Wrong than Vague!

• How can a designer assume details about uses and users?
• The answer is without even thinking about it, you're going to make these assumptions.
• Wrong assumptions are better than vague ones cause wrong ones get questioned.

Chapter 10: Inches, Ounces, Bits, Dollars -- The Budgeted Resource

What's the Budgeted Resource?

• "Within any design, there is at least one scarce resource to be rationed or budgeted" (Brooks, 120).
• If a design team wants to have conceptual integrity, then they want to name the scarce resource explicitly, track it publicly, and control it firmly.

Often Not Dollars

• Some budgeted resources that are not dollars:
• Inches of oceanfront, in a beach house
• Ounces of payload, in a spacecraft—or in a backpack
• Memory bandwidth, in any von Neumann computer architecture 
• Nanoseconds of timing tolerance, in a GPS system 
• Calendar days, on an asteroid-interception project
• Resident kernel memory space, in OS/360 design
• Program hours, at a conference 
• Pages, on a grant proposal or a journal paper 
• Power (and stored energy) on a communications satellite 
• Heat, in a high-performance chip 
• Water, on western farmland 
• Student learning hours, in a degree curriculum 
• Political power, in an organization’s constitution 
• Seconds, even frames, in a film or video 
• Hours of access to the track per day, in London Underground engineering and maintenance 
• Format bits, in a computer architecture 
• Hours or minutes, in a military assault plan

Even Dollars Have Flavors, and Surrogates

• "Even when cost is in fact to be the budgeted commodity for a design project, cost varieties must be considered" (Brooks, 121).
• Most designers adopt surrogates as their budgeted resources when it comes to money. 
• Surrogates have several advantages:
• Simpler.
• More stable.
• Designers can work with them long before they are aware of the ratio between surrogate and dollar.
• However, surrogates can lead one astray.

The Budgeted Resource Can Change

• Which resources are critical can be determined in the shifts in technology, since they change, so we are not aware of when some resources are in high demand.
• Budgeted resources can change in the middle of a design because as we learn more about the project, we become smarter and know what resources are wiser to use.
• Robert Ruthrauff built a performance simulator and got it running, but the results were horrifying. As time went on, the project's budgeted resource switched from memory bytes to disk accesses.

So What?

• Identify Explicitly
• A project manager normally begins by analyzing the constraints and objectives, then identifies explicitly the budgeted resources. 
• Often schedule may become the budgeted resource, if a company wants to be the first to market their new product.
• Track Publicly
• The whole teams should be aware of the current budget for the critical resources. 
• Control Firmly
• For critical resources, it is wise for the project manager to keep a few of these resources allocated and hidden, just in case, it is needed.

I have spent 2 hours on this assignment.