Question 1. Whereas many design theorists argue that designers commonly use "generate-test" control strategies, many architectural programming models appear to be based on "breadth-first" strategies, where all facts and alternatives are identified prior to design. Support or reject this observation and suggest the implications, if any, for programming practice. The primary claim of this question is that designing and programming are different by their nature. It also tries to imply two things: 1) many designers use depth first strategies whereas programming is breadth-first, and 2) in contrast to design, programming does not use "generate test" strategy. However, I find this question poses a false dichotomy. I will argue two disagreements with the above hypotheses. First, I will argue that though designers use "generate test" model, they do not just use it for depth searches but also for breadth searches. Second, I will argue that though programming use breadth first searches, it does not reject the "generate test" strategy. Furthermore, I will argue that programming and design are similar because they both identify stage model. I will explain that the three stage model of "analysis, synthesis and evaluation" is very similar to "generate and test" in that "synthesis" is to "generate" ideas and that "evaluation" is to "test." I basically agree the generalized observation that design is "generate test" and programming is "breadth first" stated in the question given above, yet, I question the inferred premise. Therefore, I will review the process models from both design studies research and programming disciplines to argue that both fields share similar concepts and strategies. Then I will explain different problem solving strategies by giving examples 1
from the domain of architectural design. Finally, I will discuss how different problem solving strategies might affect the practice of programming and design field. 1. What are the differences between programming and designing? In the following I will briefly present the process model from both design studies and programming approaches to argue that they are similar in many ways. 1.1. Design Studies Approach Since the early sixties, researchers have been interested in design process and described several design methods that designers commonly use. Two major models of design are relevant here and will be discussed below. These approaches are: 1) design has different stages, 2) design is a problem solving activity. These two approaches both identify design process as generating and testing of design options. First, many researchers share the idea that a design process consists of different stages. For example, Asimow in his "Introduction to Design" (Asimow 1962) argues that a design process is cyclic and can be broken down into 1)analysis of problem situation, 2) synthesis of solutions, and 3) evaluation and decision. Archer describes design procedure as programming data collection analysis synthesis development communication with emphasis on analysis, synthesis, and development (Archer 1968; Archer 1984). Markus' approach stresses the importance of performance evaluation and proposes a process model consists stages of analysis, synthesis, appraisal and decision (Markus 1969). Zeisel uses a spiral metaphor to express the nature of design development as cycling through image formation, presentation and test (Zeisel 1981). Cross argues that a simple 2
design process model consists of four stages exploration, generation, evaluation and communication. (Cross 1994). All the above models recognize "generate test" as design nature thought the concept of "generate" is represented by the term of "synthesis" or "formation," while the concept of "test" is represented by the terms "evaluation" or "decision.". Second, design is viewed as a decision making and problem solving process. For example, Herbert Simon in his "Sciences of Design" (Simon 1969) describes the design process as "information-processing" and uses the "generator-test cycle." A design process in his definition involves 1) the generation of alternatives and 2) the testing of these alternatives against a whole array of requirements and constraints to find optimal or "satisficing" solutions. "Satisfice" is a word that is composed of "satisfy" and "suffice." Christopher Jones in his "Design Methods" (Jones 1980) describes design as a three-stage process: 1) divergence, 2) transformation and 3) convergence (Jones 1980). In Jones's model, divergence means extending the boundary of the design situation to have a larger search space. Transformation is making patterns based on the divergence and creativity. Convergence is to sort through the alternatives and come to the final decision. These above models recognize design as searching in solution space. In sum, design is generally viewed as a problem solving process and involves iterative "generate" and "test" or "analysis-synthesis-evaluation" phases. 1.2. Programming Research Approach Programming, though becoming a distinct discipline, comes from the notion to aid design, inherently shares similar model with design studies research. I will argue in the 3
following that even though architectural programming can be classified as two different approaches, yet both models are similar in that they identify process as stages and problem solving. The two views of programming are: 1) an integrated view that programming is design, or is part of design, and 2) programming and design are segregated. First, programming can be viewed as design, or as a part of design. This is an integrated view. For example, most programming researchers share the notion of programming as design and is a problem solving activity with iterative nature. Henry Sanoff in his "Methods of Architectural Programming" identifies design programming as problem solving. He goes in length to describe programming method as transforming design information that has stages of 1) Analysis, 2) Synthesis and 3) Evaluation (Sanoff 1977). He uses techniques derived from design method studies such as "pattern language" (Alexander 1966; Alexander and others 1977) and "morphological approach" (Norris 1963) in his book to illustrate programming methods. Preiser in his "Programming the Built Environment" (Preiser 1985) describes programming as methods of "data gathering, synthesis, interpretation and translation." White's "Introduction to Architectural Programming" describes programming as "part of the design process" (White 1972) and is composed of "gathering, analyzing, organizing and presenting information pertinent to the design problem." Palmer in "The Architect's Guide to Facility Programming" argues that "Programming is an information-processing process" (Palmer 1981). In other words, in this integrated view, programming is information processing through the stages of analysis, organization, and evaluation. Second, programming can be viewed as a separate matter to design that should precede design. This is a segregated view. For example, several books propose programming as a phase that precedes design. AIA's "Emerging Techniques of Architectural Practice" 4
(Wheeler and others 1966) lists the phases of a project as 1) programming phase, 2) schematics phase, 3) design development phase, 4) construction documents phase, and 5) construction administration phase. As Preiser points out (Preiser 1985), most examples described in his edited book "Programming the built environment" share the view that programming precedes design in the building delivery process. Another example, the influential "Problem Seeking" (Pena and others 1977) particularlly emphasizes the necessary distinct separation of programming and design. The book states that "programming precedes design just as analysis precedes synthesis." Therefore, programming is defining the problem for design to solve. The book further suggests that programming consists of five steps: 1) establish goals, 2) collect and analyze facts, 3) uncover and test concepts, 4) determine needs, and 5) state the problem. Interestingly, thought this approach emphasizes the segregation of programming to designing, the approach is fairly similar to the design process model of "generate and test" concept. In short, programming researches share with design studies similar notion of problem solving process though they might hold different views (integrated or segregated). I shall conclude from above that programming is similar to design with more emphasis on the collecting and analyzing of data with the intentions to help create a better design. 2. Is programming a "breadth-first" approach? 2.1. Search Strategies in Problem Solving In this session, I shall argue that a statement like the question given in the beginning for this essay stating that programming is "based on breadth-first strategies" is correct if we view the data collecting part as programming design, "where all facts and alternatives are 5
identified prior to design." Yet, it is not completely true to view programming as using only "breadth first strategies. I will present Duerk's programming model (Duerk 1993) to show that programming can also be viewed as a "depth first" approach when a concept is derived through the path from stages of mission statement, goal identification and performance requirements. Duerk also proposes a ten step process that in a broad sense can also be viewed as a generate test model. Let me briefly review search strategies for problem solving. Assume a problem is soluble and has a huge search space that contains the solution. The search space is like a maze (Simon 1969) or a search tree. This search tree can be called as a problem behavior graph (PBG) (Newell and Simon 1972). A tree starts with a top node and single links to other nodes that represent the possible outcome state and decision point. To solve a problem, we need to have a strategy to search for the solution. Of course we can test all the possible solutions to find an optimal one, but this will be very time-consuming. Researchers (Raphael 1976, Simon 1979; Winston 1984) suggest careful planning before actual problem solving activities start and come up with several different control strategies. Three important problem solving strategies will be discussed here. They are depth first, breadth first and satisficing first. A mind (or a program) in a depth first search follows its first idea (option node) to its limit (bottom node) before turning back to consider other alternatives. The selected route is completely explored until its dead end, then the search path would turn back to nearest point to explore the next down option (Figure 2a). In a breadth first search, the mind explores all the nodes at a level before going down the tree (Figure 2b). Both depth-first and breadth-first strategies are exhaustive. To save time, heuristic method that searches for a 'satisficing first' (satisfy + suffice (Simon 1969)) will evaluate and estimate promising nodes to avoid exhaustive search (Figure 2c). 6
Let's now use examples of architectural design to illustrate depth first, breadth first and satisficing first approaches. In Figure 1, I make up a simplified version of a design approach tree with no intention to declare its completeness but to show the hierarchical relationships between nodes and links. The top node #1 is a basic design concept that can be a program brief, or a general mission statement of a design. The second level nodes are different aspects and approaches to start designing, for example, a design investigation can start from structure aspect (#2a) or siting considerations (#2d). A structural design approach can take form (#3a) as major factor and go further down the tree to explore different building material such as wood (#4a), steel (#4b) or concrete (#4c). 1. Design 2a. structural 3a. form 4a. wood 4b. steel 4c. concrete 2b. space 3b. layout 4d. workspace 4e. bathroom 2c. environment 3c. control 4f. furniture 4g. acoustics 4h. lighting 4i. heating 2d.site 3d. sitting 4j. landscape 4k. recreation 4l. parking Figure 1. A simplified tree of design approach A breadth first strategy for design, as shown in Figure 2a, will start from the top node #1 then explore all nodes of level two: 2a, 2b, 2c, 2d before going to level three: 3a, 3b, etc. 7
1 2a 3a 4a 4b4c 1 2a 3a 4a 4b4c 1 2a 3a 4a 4b4c 2b 3b 4d 4e4f 2b 3b 4d 4e4f 2b 3b 4d 4e4f 2c 3c 4g 4h4i 2c 3c 4g 4h4i 2c 3c 4g 4h4i 2d 3d 4j 4k4l 2d 3d 4j 4k4l 2d 3d 4j 4k4l a Bredth-first b Depth-first c (same levell nodes first) (deeper level nodes first) Satisficingt-first (explore until find satisficing one) Figure 2. Different search strategies A designer after reading design needs (#1) will first sketch out several schemes based on structure (#2a), space (#2b), environment (#2c) and site (2d) before further considering the next level concerns such as structural form (#3a) or layout (#3b) before go down to next level approaches such as trying different materials and allocating different spaces (#4a, 4b, 4c, 4d, etc.). A depth first strategy for design, as shown in figure 2b, will be go down from 1, 2a, 3a, until to the end 4a before go up to 3a and go down to 4b. The example will be a designer starting design (#1) with concept of using structure (#2a) as theme and go in detail to develop form (#3a) by using wood (#4a) construction method before explore next possible solution of using steel (#4b) construction method. A satisficing strategy, as shown in figure 2c, will combine the depth and breadth search until finding a satisficing option. This satisficing strategy will not necessary find the best option from the search space, but is satisfying and sufficient enough to target the intended goal. For example, a designer might start the design (#1) by exploring structure (#2a), space (#2b) and environment (#2c) factors and find environmental (#2c) approach 8
satisficing and decide to go deep into exploring the environmental control (#3c) concerns by focusing on acoustics (#4g) issue. 2.2. Nature of Architectural Programming, breadth first vs. depth first search In this session, I will briefly review how programming researchers view programming, and discuss whether programming is a breadth first or depth first approach. Programming is viewed similar to design as problem solving process. Preiser (Preiser 1985) argues that programming is "intended to facilitate communication among the designers and providers of the built environment, as well as facility managers, and the eventual user/occupants." It is also an information processing system that has ingredients for "sorting conflicts and decision making" (Sanoff 1977). Sanoff defines a program as a communicable statement of intent, "an operating procedure for systematizing the design process." He argues that it is disadvantageous to use the natural problem solving strategy of developing the first solution generated (I will call this a depth-first approach) because it may not be the best solution. Therefore, in chapter 2, Analytic Methods of Information Retrieval, Sanoff describes several methods such as behavior, comparison and rating methods to analyze and evaluate design problems. He views the system as "moving toward control and feedback." The system would evaluate a set of conditions and generated alternatives. Since Sanoff rejects the depth-first approach, I think it is fair to call his model a breadth first or a satisficing first approach. He uses "evaluation" as "testing" mechanism to decide good solution. Therefore, I conclude that architectural programming uses "breadth-first" strategies and "generate test" model. 9
However, I shall argue that programming can also be depth first. For example, following the line of Sanoff's rejection of "natural problem solving strategy" of developing first solution generated first, it implicitly shows that depth first is probably the way programmers' natural way of programming, therefore he proposes breadth first strategy to reject it. Besides this speculation, Duerk in her "Architectural Programming" defines architectural programming as the process of "gathering information, analyzing that information and making recommendations for the performance of a building." She proposes a tree structure hierarchy for programming as depicted in figure 3. The development of a bottom node "concept" is a working through original top node "mission" to lower levels to set up a "goal" and a specific "performance requirement." Therefore, I shall argue when a concept is derived through this path, it is a "depth first" strategy. Nevertheless, when a programmer starts investigation by listing all the possible goals before writing down all the possible performance requirements, this approach is a "breadth first" strategy. Mission Goal Performance Requirement Concept Goal Performance Requirement Concept Figure 3. Duerk's programming process diagram In sum, programming is generally proposed and observed as breadth first approach though some concept development process are actually depth first. 10
3. What are the implications? 3.1. Questioning the inferred premise of the question. Basically in general, I support the statement of the question that design is "generate test" while programming is "breadth first." Nevertheless, I argue that the above statement is not a complete picture. First of all, the question suggests a contradiction, but design and programming are not in opposition, they are similar in many ways. Secondly, "generate test" model applies to both depth first and breadth first. Let's summarized what have been discussed in this essay. First, the question set up to contrast designing and programming, yet, I argue that design is not completely in contrast to programming as merely being "depth first." We have the impression of design as depth first strategy because designers usually stick to a preferred path to develop design to an extend of detail before they move for another approach. However, they also perform breadth first searches when they list out all possible options to approach design. Second, designers use "generate test" model not only in the sense of depth first but also the breadth first searches. Sometimes they develop a case all the way to exhaust until the end and evaluate the outcome of the scheme. Sometimes designers perform evaluation and testing for depth searches. Sometimes they perform a modified depth-first and breadth first approaches to generate several possible alternative cases, and examine only their immediate next steps for evaluation and testing which is a "satisficing first" approach. Therefore, I conclude designers use "generate test" in all different strategies not just for to "depth first.". Third, I have also shown examples that the process of programming is similar to "generate test" and it does not just limit to "breadth first" 11
strategies but also executes "depth first" while structuring information hierarchy. All the discussion of different process models from design and programming fields, and the illustration of different control strategies are to show that design and programming are similar in that they use "generate test" and stage models and view the process as "problem solving" by using both "depth first" and "breadth first" searching strategies. 3.2. What are the implications to programming? Is programming ineffective? Should it be reformed or rethought? I wouldn't say programming is ineffective even though many designers might reject the idea that they need programmers. It is clear from both design studies and programming researches that programming practice is embedded in the design process whether as a form of "problem solving" or "problem seeking." The development of programming as an independent discipline is aiming to aid better design. A well prepared program identifies problems and helps steering direction for design. Designers might protest that having an elaborate program will obstruct their creativity and freedom to design. They prefer to express their preference of design approaches and express their style. Style, however, can be seen as a way of doing things when choosing a "satisficing" option (Simon 1969; Simon 1975). I believe to be able to choose a "satisficing" solution is to use preference and past experience to detect achievable good enough options. Therefore, a programmer in a design team should be familiar with this design team's past design cases and preference to help set up design goals and approaches to maintain that particular design team's style. In this sense, a program fails when it allows designer to achieve only one best solution. Since a best design is unattainable, therefore, a program should identify possible solution zone and flexible concepts instead of making solid recommendation. 12
4. References Alexander, Christopher. Notes on the Synthesis of Form. Cambridge: Harvard University Press, 1966. Alexander, Christopher, Sara Ishikawa, Murray Silverstein, Max Jacobson, Ingrid Fiksdahl-King, and Shlomo Angel. A pattern language : towns, buildings, construction. New York: Oxford University Press, 1977. Archer, L. Bruce. An overview of the structure of the design process. In Emerging methods in environmental design and planning, ed. Gary T. Moore. 285-307. Cambridge, MA: MIT Press, 1968. Archer, L. Bruce. Systematic Method of Designers. In Developments in Design Methodology, ed. Nigel Cross. 57-82. Chichester: John Wiley & Sons, 1984. Asimow, Morris. Introduction to Design. Fundamental of Engineering Design, ed. James B. Reswick. Englewood: Prentice Hall, 1962. Cross, Nigel. Engineering design methods : strategies for product design. Chichester: Wiley, 1994. 13
Davis, Gerald. The Relationship of Evaluation to Facilities Programming. In Symposium of Evaluation of Occupied Designed Environments in Atlanta, GA, Georgia Institute of Technology, 1982. Duerk, Donna P. Architectural Programming-- Information Management for Design. New York: Van Nostrand Reinhold, 1993. Jones, J. Christopher. Design Methods. New York: John Wiley & Sons, 1980. Markus, Thomas A. The role of building performance measurement and appraisal in design method. In Design Methods in Architecture, eds. Geoffrey Broadbent and Anthony Ward. 109-117. New York: George Wittenborn, 1969. Newell, Alan and Herbert A. Simon. Human Problem Solving. Englewood Cliffs, NJ: Prentice Hall, 1972. Norris, K. W. The Morphological Approach to Engineering Design. In Conference on Design Methods, eds. J. Christopher Jones and D. G. Thornley. New York: Macmillan, 1963. Palmer, Mickey A. The Architect's Guide to Facility Programming. New York: AIA & McGraw-Hill, 1981. Pena, William, Steven Parshall, and Kevin Kelly. Problem Seeking, an Architectural Programming Primer. Washington: AIA Press, 1977. 14
Preiser, Wolfgang F. E., ed. Programming the Built Environment. New York: Van Nostrand Reinhold, 1985. Sanoff, Henry. Methods of Architectural Programming. Stroudsburg, Pennsylvania: Dowden Hutchington & Ross, Inc., 1977. Simon, Herbert A. The Sciences of the Artificial. Cambridge, MA: MIT Press, 1969. Simon, Herbert A. Style in Design. In Spatial Synthesis in Computer-Aided Building Design, ed. Charles M. Eastman. 287-309. New York: John Wiley & Sons, 1975. Wheeler, C. Herbert, Melvin W. Isenberg, Gifford H. Albright, Donald E. Dougald, Larry O. Degelman, and Ben H. Evans. Emerging Techniques of Architectural Practice. New York: The American Institute of Architects, 1966. White, Edward T. Introduction to Architectural Programming. Architectural, University of Arizona, 1972. Zeisel, John. Inquiry by Design. Monterey, CA: Brooks/ Cole Publishing, 1981. 15
The image part with relationship ID rid10 was not found in the file. 16