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.