Design of Design - Summary of Chapters 13 - 14

Chapter 13: Exemplars in Design

• Few Designs Are All-New
• But These Surely Are Fun!
• Rarely does a designer see a design that is completely new.
• The Common Lot.
• Most designers derive from found facts that are intended for similar purposes and built with the same technology.
• The Role of Exemplars
• "Exemplars provide safe models for new designs, implicit checklists of design tasks, warning of potential mistakes, and launching pads for radical new designs" (Brooks, 154).
• That's why great designers took the time to find and understand what has already been discovered by others.
• What about Computer and Software Design?
• A great design follows older design disciplines, but nowadays we have improved greatly in learning the new ways of the modern science.
• What Exemplars Do You Use?
• Computers.
• Designs adapt well in a common field.
• Hence people who work for a certain company, can do a better job designing something for that company because he/she knows better how to make their design adjust with the company and adapt with it well.
• Mass-Product Software
• "Products such as Microsoft Word have followed the design pattern of computers, with successive generations created by progressively modifying function an implementation" (Brooks, 156).
• Custom Application Software and Operating Systems.
• The building and architecture of software solely relies on the experience of the designer instead of the individual themselves. Each person deals with certain tasks depending on what they are good at, and what they feel comfortable knowing.
• Studying Design Rationales of Exemplars
• To overview about a product, the designer has the studying the technical papers and other books about the product.
• Technical papers emphasize what the product and sometime goes over the why of the paper.
• First-Generation Computers
• " The most important computer paper ever written is "Preliminary discussion of the logical design of an electronic computing instrument""(Brooks, 157).
• After many designers read this paper, many designer tried to successfully build a store-program computer.
• Third-Generation Computers
• "Second-generation computer architectures ran out of gas; that is, they lacked enough address bits to handle the large memories that had become economical and indispensable" (Brooks, 158).
• High level language allowed for recompilation and integrated circuits provided a great deal of insight in their realization cost.
• Virtual Memory
• "The Manchester Atlas introduced the automatic paging of blocks instructions and data from a slower backing store into a smaller high-speed memory" (Brooks, 159).
• The Minicomputer Revolution
• Transistor-diode logic changed the way computer where made. It drastically made it cheaper to think about a computer.
• The Microcomputer and RISC Revolutions
• With integrated circuits,  a revolution took place making it cheaper for individuals to own a personal computer/machine.
• 
  
• What Should a Discipline Do to Improve Exemplar-Based Design?
• Collection of Exemplars
• This section show that there are plenty on exemplar designers.
• Beyond Collection
• After carefully overviewing the collection, all you have to deal with is an even-handed criticism for each particular exemplar.
• Next step after criticism would be analysis.
• What about Software Design?
• Software design has been developed and improved for a long time, that's why it has progress so much thought collections, criticisms, and analysis.
• Who?
• "Systematizing exemplars for study is a task of scholar- ship, not of design. Scholars and designers are different in taste and temperament" (Brooks, 161).
• How Encouraged?
• "Does modern engineering academia value and praise the work of the systematizer? Can one get tenure for doing such? In many institutions this work would be valued in a History of Science and Technology Department, but not in an Engineering Department" (Brooks. 161).
• Exemplars -- Laziness, Originality, and Pride.
• "Whoa! The above discussion on exemplars in design skips lightly by some issues very real for each designer:
• Isn’t copying an early design, a precedent, just an exercise in laziness? Can an honest professional do that with integrity?
• People become designers because they like to make things. What fun is there in confining one’s self-expression within the iron cage of another’s style?
• The world highly values originality and innovation and rewards them with respect, reputation, and sometimes fame and fortune.
• One’s special contribution to the human race depends upon one’s own unique vision. Isn’t it a disservice to neglect or suppress this originality?" (Brooks, 162).
• Some Perspective
• Brooks does not assert that exemplars who have adapted to the design can easily solve most design problems.
• However Brooks does assert that:
• The designer should know well the exemplars of his craft, their strengths, their weaknesses. originality is no excuse for ignorance.
• In engineering, if not in the arts, gratuitous innovation (that is, not anticipated to be “better” in some useful sense) is a foolish idea and a selfish indulgence of pride—because of the unavoidable risk of unintended downside consequences.
• Designers who master the styles of their predecessors have more treasures upon which their originality can draw.
• Laziness
• The world is full of lazy designers who hardly do any work. These lazy designers can minimize work, instead of picking an exemplar and modifying it to fit.
• However most lazy designers just copy the work and do not draw any conclusion that someone who isn't lazy can. 
• For instance, the ancient designers who have become exemplar over the years.
• Originality and Pride
• Designers try to meet their functional needs and make sure that their design is robust, and durable under stress.
• Originality as Goal or By-product.
• "He who seeks originality is apt to find novelty, but not permanence of delight. On the other hand, he who seeks to make designs that really work is most apt to come up with new designs of enduring value, almost as a by-product" (Brooks, 163).
• Pride.
• "Closely tied to the striving after originality is pride, a desire to make a name for oneself. This ancient cause and consequent of humanity’s fall infects all design, and ruins much" (Brooks, 163).

Chapter 14: How Expert Designers Go Wrong

• Mistakes
• Brooks believes that a designer with less experience tends to make mistakes that a professional person would not make.
• However when professionals make mistakes, it is normally a large mistake.
• Sometimes it can affect the construction on the product.
• Henry Petroski lists a few of things that designers do regardless of experience.
• Tread cautiously at first.
• Master the new approach.
• Begin to extend it boldly, often forgetting the underlying assumptions.
• Overreach in their boldness and self-confidence, pressed perhaps by hubris and competitiveness.
• "Success is dangerous for the professional designer. Failure stimulates analysis, scrutiny, rethinking. Success stimulates confidence both in design technique and in oneself. Both trusts may be misplaced" (Brooks, 169).
• The Worse Computer Language Ever
• Brooks explains that one failure caused by experts has to be IBM's Operating System / 360 Job Control Language (JCL).
• What's JCL?
• OS / 360 was designed to be a batch operating system, however the first terminal users could interact with each other by sending job into the queue, setting them up, inquiring its status, and results of the jobs done.
• JCL was a scripting language that specified the options for computer a batch job.
• So What's Wrong with JCL?
• "The biggest flaw of all was that JCL is indeed a programming language, but it was not perceived as such by its designers" (Brooks, 170).
• One Scheduling Language for All Programming Languages.
• Each user of the OS/360 concept must know at least two languages, one of these required languages was JCL, then the second could be any language of his choice.
• Designers wanted schedule-capability instead of a single schedule-time language.
• Like S/360 Assembler in Syntax, Rather than a High-Level Language.
• "Having mistakenly decided to have one schedule-time language, the designers chose the wrong one. As early as 1966, one year after the full OS/360 was up and running, assembler- language jobs accounted for only about 1 percent of all jobs. A major paradigm shift had happened, and it wasn’t recognized" (Brooks, 170).
• But Not Exactly Like S/360 Assembler Syntax.
• "Enough deviations crept into JCL that knowing S/360 Assembler syntax did not mean knowing JCL syntax (Brooks, 170).
• Card-Column-Dependent.
• A paradigm was taking place, and being pushed, however, the system wasn't recognizing it.
• "Fortran, for reasons having to do with the 36-bit word of the IBM 704 (1956), allowed statements of 72 characters, plus continuation lines. Characters beyond the 72nd in a line were ignored" (Brooks, 171).
• Too Few Verbs.
• "The designers’ proud boast was that JCL has only six verbs: JoB, EXEC, DD, and so on. And so it does. But the number of functions the language has to perform far exceeds six.2 With an imposed “elegant” simplicity not up to the actual complexity inherent in the task at hand, the complexity inevitably breaks out in jury-rigged solutions" (Brooks, 171).
• Declaration Parameters Do Verbish Things.
• "The verb functions have to be provided somehow. So in JCL a Data Declaration (DD) statement is provided with a (too-)rich set of keyword parameters. Many of these are imperative verbs in disguise, such as DISP, which commands what to do with the dataset after a job step ends" (Brooks, 171).
• Almost No Branching.
• "Central to most programming languages is the concept of a conditional branch. JCL has no such central concept—branching is an afterthought, restricted in action, achieved through a parameter" (Brooks, 171).
• No Iteration.
• "There is no direct primitive in JCL to accomplish iteration; it must be fashioned out of the awkward branching. The designers did not imagine an iterative action in a schedule- time script" (Brooks, 171).
• No Clean Subroutine Call.
• "Similarly, the designers did not perceive any need for a subroutine call in a schedule-time script. This is harder to understand, for many JCL programs make extensive use of open subroutines, that is, repeated sequences of commands identical except for a few parameters" (Brooks, 171).
• How Did JCL Get That Way?
• Designers who worked on this language brought too much experience into the task, hence users like us who don't have much experience tend to not want to learn JCL.
• "Few types of control cards did indeed characterize the 1410/7010 operating system, and fewness equated to simplicity as a goal for oS/360 JCL. This led to having too few verb types. Not only was fewness of card types wrong; so was the implicit assumption that each job would be controlled by a few cards of each type. In the event, JCL scripts usually contained dozens of statements" (Brooks, 172).
• One problem discovered was that most designers believed that JCL was nerver really designed. If the designers who designed it had thought of it as a language, then perhaps there was hope.

I have spent 2 hours on this assignment.