Architectural programming: problem definition and its relation to design process

Abstract

There is, currently, considerable evidence of confusion and conflict within the profession of architecture. This conflict stems from three major factors. These are: i) The Technological Age ii) The Complexity of Problems iii) The Client. Each of these is examined; the conclusion being that for architecture to develop, defined Process or Method is needed. Scientific Method is then examined to find the roots of Process. The argument is that architecture can, and must, learn Method or Process from the Technologies. The conclusion is that for any Process, the first step is the initial definition of the problem. This problem statement (with respect to Architecture) is difficult, since it involves non-quantifiable goals statements and concepts. The Process whereby this Problem Statement is achieved has been defined as Programming. This definition involves Areas of Concern and results in Criteria for Programming, which are: a) Flexibility b) Feedback c) Experience d) Communication These criteria are then used for evaluation of the Case Study. The first part of the case study examines, in detail, the Programming process of a large architectural firm. Part two examines four other Programming Processes, in less detail. The study is then evaluated by re-stating the definition of Programming, and describing various potential uses of Programming and concludes in the statement of two over-riding considerations for Programming. These are:- 1) The Statement of the Problem is the product of Programming. 2) Programming and Design are Processes within an overall Project Delivery System. The envelope which contains them is Management; and their interface is the Statement of the Problem. The appendix contains illustrations of techniques used by the firm for the specific case study, together with documentation and evaluation of three different uses of their Programming Process. A comprehensive bibliography completes the document.