Design of Design - Chapter 20

Brooks opens this chapter by distinguishing two different groups: rationalists and empiricists. He states that rationalists believe that a complex object can be designed by thought alone, but empiricists believe the exact opposite. He states that rationalists would say that you should design software to be correct, and then prove that it's correct. Brooks ends this short chapter by answering a question he posed at the beginning of the chapter. He says that you can't design a complex object just by thinking hard about it, but it does help.

Design of Design - Chapter 19

Brooks opens this chapter talking about constraints. He tells us that constraints can be a good thing that challenge a designer's thinking, or they can be bad things that make a designer's life exceptionally difficult. Different types of constraints have to be identified, so Brooks lists four different types: real, obsolete, incorrectly perceived as real, and intentionally artificial. Two of these are quite obvious, but obsolete and incorrectly perceived constraints are less obvious. Brooks explains obsolete constraints by alluding to old size constraints that programmers had to adhere to in the past. He then explains incorrectly perceived constraints with several figures. Brooks then gives us an interesting idea. He says that specialized designs with tight constraints are easier than general-purpose designs with loose constraints.

Design of Design - Chapter 18

One of many problems with the model is that you're supposed to have a primary objective, but you might not always know what that is when you first start. He said that he began to realize at some point that his real use to his client wasn't for making goals and such, but actually for helping the client to determine what he actually wanted. Another problem with the model is the design tree. Similarly to setting the goals, we don't always know what the design tree looks like when we are first starting out. Furthermore, the design tree is far too simplistic. The nodes don't represent design decisions, but instead complete designs. Also, determining which path is the "best" to take while traversing the design tree is not feasible. Oftentimes, too many variables go into determining what is the best choice that you can't make a good decision by just looking at a design tree. The author also points out that, as the design process carries on, certain things may come to light that warrant a drastic design change.

Design of Design - Chapter 17

Brooks starts this chapter by helping us to see why setting too many requirements early on is a bad thing. If you have many people, all with their own agendas, trying to put their own lists of requirements into a design, the end result will often be bloated and not as functional as they should be. The author explains to us that a designer should start with a few high priority requirements, all with their own "weight," and then break them down into sub-requirements as the project progresses. And, if the focus on requirements starts to drift to other things and the creation of new requirements, usually the urgency of meeting a deadline and keeping to a schedule will help to combat these things. Another solution to "requirement creep" may be to appoint knowledgeable project managers from the very beginning of the project. Also, Brooks points out the necessity of written contracts. The author then closes the chapter by talking about the building designing model and how it separates the contract for design from the contract for construction.

Design of Design - Chapter 16

Brooks starts this chapter by posing a few questions about how to find a better design model, or if it even matters at all. He then introduces us to the Co-Evolution model.With this model, you incrementally evaluate you problems and your solutions. Then, Brooks introduces another alternative model called the Bazaar model. This model deals with open source and using members in the community to help with your design. However, he points out that the results might not be as polished or debugged. Finally, he gives us the last model of the chapter: Boehm's Spiral model. This model emphasizes prototyping and performing user tests very early in development.

Design of Design - Chapter 15

Brooks starts this chapter by describing outlandish design requirements that were thrust upon him by the Marine Corps. By telling us this story, he is helping us to see why setting too many requirements early on is a bad thing. If you have many people, all with their own agendas, trying to put their own lists of requirements into a design, the end result will often be bloated and not as functional as they should be. The author explains to us that a designer should start with a few high priority requirements, all with their own "weight," and then break them down into sub-requirements as the project progresses. And, if the focus on requirements starts to drift to other things and the creation of new requirements, usually the urgency of meeting a deadline and keeping to a schedule will help to combat these things. Another solution to "requirement creep" may be to appoint knowledgeable project managers from the very beginning of the project. Also, Brooks points out the necessity of written contracts. The author then closes the chapter by talking about the building designing model and how it separates the contract for design from the contract for construction.

Design of Design - Chapter 14

This chapter begins with "how engineers think of design." The designer can make a design tree. The design tree is the illustration of the different possible paths created by increasingly narrowing decisions about your design. The author points out that this tree can be operated on in the same way that any other tree data structure can be. The step-by-step design process model was developed in the community of German mechanical engineers. It has since been built upon by people such as Winston Royce, who created the seven-step Waterfall Model. The chapter closes with a paragraph explaining some of the benefits of using the Rational Model.