Epistemic Implications of Engineering Rhetoric Citation

The texts (and talk) of engineers take different forms. In this essay, I present and critique several texts written for different purposes and audiences but all intended to convey to the reader the technical details of whatever they are about whether a textbook passage describing the fundamental behavior of an electrical component, a journal article about a mathematical technique intended for use in design optimization, a memo to co-workers within a firm about a heat transfer analysis of a remotely sited building, or a general introduction to the field of ‘ergonomics’. My aim is to explore how the ways in which engineers describe and document their problems and projects frame what they accept, display and profess as useful knowledge. In this I am particularly interested in how engineers envision the 'users' of, or participants in, their productions. Like science, engineering texts are written as if they were timeless and untainted by socio-cultural features. A technical treatise is not devoid of metaphor or creative rendering of events; there is always a narrative within which worldly data and instrumental logic is embedded but it is a story in which the passive voice prevails, history is irrelevant, and the human actor or agent is painted in quantitative parameters fitting the occasion. Whether this rhetoric can be sustained in the face of challenges to traditional ways of doing engineering is an open question. I am concerned with the way engineers, primarily academics, express themselves in their text books, journal articles, reports and memos and how this relates to engineering knowledge as trusted, deployed, and enlarged upon in a research project, in the classroom, in the design of a product. “Rhetoric” is to be understood in an honorable sense, as the crafting and presentation of argument intended to explain and persuade not simply or crassly, as “ornamental writing”. My interest, though, is not in “persuasion” per se as exemplified in an engineering faculty proposal to NSF seeking funds to support her research program but in more ordinary, mundane texts that are written for, and used in, the classroom, the laboratory, the product design and development process1. My thesis is, first, that the way engineers write about, describe and document their problems and projects frames (reflects and constrains) what they accept, display and profess as useful knowledge. Second, this rhetoric is in need of revision in the light of the new demands placed upon the engineering practitioner2. I have selected texts from different contexts and different engineering domains. The first, drawn from a university level electronics textbook, is about the behavior of a diode; the next presents excerpts from a journal article about a computational algorithm for optimizing the design of complex systems; then follows an analysis of a company memo about energy requirements for a guard house located at an oil field in the Arabian peninsular; a final textbook selection is concerned with “human factors” in the design of manufacturing processes. I also include as a preliminary, and in the closest I come to persuasion, a brief selection from a draft of a report prepared by an interdisciplinary faculty committee at MIT describing a new engineering course on “engineering method”. Most of this writing is narrowly focused and strictly instrumental -or so it seems at first reading; the challenge is to try to wring out of the text certain implications about engineering knowledge what it is, what it is not and how the rhetoric enables and constrains engineering thought and practice. 1. My purpose is not to critique, none the less fully explain the text’s technical argument; the analyses one finds in textbooks and journal articles have been through the peer review and most likely are rigorous and watertight. Unless there is some glaring error, I presume that the author has gotten it right. 2. Ahearn, Alison L., “Words Fail Us: the Pragmatic Need for Rhetoric in Engineering Communication”, Global J. of Eng. Educ., vol. 4, no. 1, 2000, pp 57-63. 1 Copenhagen October, 2005 L.L. Bucciarelli Of particular interest is the way engineers write about human behavior -and this in two ways. In their work, engineers must take into account the behavior of the potential users of their products and systems. We shall see that the way they characterize the user will depend upon their technical interests and responsibilities in design. But they also write about the “things” they shape and design as if they alive and kicking. This too is of interest. Engineering knowledge is for solving problems Before presenting and analyzing representative texts used in the engineering curriculum, a word about what faculty perceive engineers do with the knowledge these texts are meant to provoke and the nature of the tasks to which such knowledge is considered essential. What do engineers need to know to do what they need to do? Most faculty agree that the design and development of new products and systems generally requires the coordination of a team or group of individuals from different specialties who work on different features of the system. Each participant in design will have different responsibilities and more often than not, the creations, findings, claims and proposals of one individual will be at variance with those of another. While they all share a common goal at some level, at another level their interests will conflict. As a result, negotiation and “tradeoffs” are required to bring their efforts into coherence. I enhance this picture, claiming that each participant in the task inhabits his or her own world of professional practice a world situated with respect to a particular infrastructure with its own unique instruments, reference texts, prototypical bits of hardware, special tools, suppliers’ catalogues, codes, and regulations. The world contains particular devices, recommends certain methods, and employs specialized modes of representation. There are exemplars, standard models of the way things work from the disciplinary perspective of the particular world, unwritten rules, and particular metaphors which enlighten and enliven the efforts of inhabitants. There are specialized computational algorithms, specialized ways of picturing states and processes. Each participant works with a particular system of units and with variables of particular dimensions certain ranges of values perhaps. Dynamic processes, if that is their concern, unfold with respect to a particular time scale for someone’s world it may be milliseconds, in another’s, hours or days. Within each of these worlds one “speaks” a different dialect a “proper” language, all neat and tidy, precise1. I say that different participants work within different object worlds A structural engineer inhabits a different world from the electronics engineer working on the same project. It is for work within these object worlds, these specialized domains where instrumental rationality reigns supreme, that engineering curriculum are intended. Major programs in engineering focus, at their core, on a subset of paradigmatic sciences and problems and exercises that are amenable to analysis by the concepts, principles and methods peculiar to the phenomena they explain. Most all of the texts I analyze are the product of, or intended for, object-world reading and application. Engineering faculty see object-world knowledge as the hard core of engineering knowledge. It is knowledge of a powerful sort the kind that can solve problems. Solving problems is a persistent theme running through texts addressing what engineers do. Here, for example, is an excerpt from a well-know textbook in engineering mechanics. The main objective of a basic mechanics course should be to develop in the engineering student the ability to analyze a given problem in a simple and logical manner and to apply to its solution a few fundamental and well-understood principles2. The mechanics problem is given not to be formulated by the student; it demands a simple and logical analysis not a conjectural, inferential thinking up and about; and is to be solved using a few fundamental and wellunderstood principles not by trying several, alternative, perhaps conflicting, approaches and perspectives. The work-life of an engineering student, hence graduate, is neat, well posed, deductive and principled. If we 1. Bucciarelli, L.L., “Between thought and object in engineering design”, Design Studies, Vol. 23, No. 3, May 2002. 2. Beer, F. P., Johnston, E. R. Jr., & DeWolf, J. T., Mechanics of Materials, McGraw-Hill, 4th ed., 2006, p. xiii 2 Copenhagen October, 2005 L.L. Bucciarelli were to ask what engineers do with the specialized knowledge of object worlds, irrespective of specialty, the texts say problem solving. A claim made by members of MIT’s, School of Engineering Council for Undergraduate Education charged with the task of defining the objectives of a course to be required of all MIT students a course intended to teach the Engineering Method provides another example. “...despite the myriad disciplines and domains where engineering is developed and applied, there is a common theme, a unified approach and foundational knowledge that embodies what engineering is: The major common themes of this engineering method [are]: (a) an integrated, interdisciplinary view of problem solving. (b) the concept of abstraction; (c) development of larger abstractions and model; and (d) design and synthesis...”1 What is common to all fields of engineering, then, is method for problem solving. Knowledge is knowledge of how to solve a (given) problem. Abstraction and reduction, based in the mathematical sciences, are key to this universal method. In an elaboration of the concept of “abstraction”, simplification is stressed and quantification deemed essential: [Abstraction requires] Simplification of a complex problem by breaking it down into manageable components. Specifically modeling in quantitative terms critical aspects of the physical and human world, and necessarily simplifying or eliminating [my emphasis] less important elements for the sake of problem analysis and design...2 Here we find a further qualification of what constitutes legitimate engineering knowledge: For a problem to be treated as an engineering problem it must be expressed in quantitative terms. Only factors, aspects and feature of this big world that can be construed as measurable and quantified matter. Numerical measures of inputs, outputs, parameters, variables, behavior and performance, costs and benefits are the essential ingredients of a problem. One might wonder what criteria are used in eliminating, or deforming, more qualitative elements for the sake of problem analysis and design. Is it perhaps the case that only those “elements” that can be quantified are considered at all? Anything that can’t be measured is, ipso facto, irrelevant, not of interest or significance? (Hence not complex?) McCloskey, in a provocative critique of the rhetoric of economics, identifies this sort of behavior with that of the person who, having lost his keys, searches only around the base of the lamp post because that’s where the light shines3. Even engineering design can be cast as problem solving. In Engineering Design for Electrical Engineers, design, at first reading, appears to be something more “...[a] creative process of identifying needs and then devising a product to fill those needs...” a process that can be broken down into two parts: “... first you make a project plan, then you implement the plan”. But then these too become problems to be solved: Both parts of the creative design process require problem solving. Determining the information that you need (in order) to set the design specifications is a problem. Likewise, it is an equally substantial problem to design the product. Both can be addressed by the same problem-solving techniques4. 1. “From Useful Abstractions to Useful Designs Thoughts on the Foundations of the Engineering Method, PART II, A Subject to Satisfy a GIR in the Engineering Method Educational and Pedagogical Goals and Sample Curriculum” Draft, 7 May, 2005, Engineering Council for Undergraduate Education, p. 3 2. Ibid, Part I, p.4 3. McCloskey, D.N., The Rhetoric of Economics, Univ. Wisc. Press, 2nd ed., 1998. 4. Wilcox, A.D. et al, Engineering Design for Electrical Engineers, Prentice-Hall Inc, 1990, p.3. 3 Copenhagen October, 2005 L.L. Bucciarelli Block-diagram rhetoric A block diagram follows, one that (literally) frames the problem solving method as a sequence of steps, done sequentially, as one haltingly travels down the diagram. The possibility of breaking out of the sequence is allowed at the evaluation step where backtracking to the previous stage is allowed1. This movement through time is all contained in a box. The action is all in the present tense. The box can be set down anywhere in time; the method applied at any point in history yesterday, today, or tomorrow. This holds for the questions, e.g., “...Is it reasonable?” as well as for the imperatives “Evaluate solution” (now, at this step). The passive voice prevails throughout. Who acts at each of the steps is not specified. It might be a lone individual responsible for the whole; or a different individual might be engaged at each step; or a team of two or three or five hundred might be charged with carrying the ball from top to bottom. Alternatively, one can interpret the diagram as showing the workings of a problem solving machine, a device, an artifact which, once fed the causes, requirements, constraints and set in motion, cranks away synthesizing, evaluating, deciding and finally delivering a solution for action. In this light, the diagram shows a timeless, universally applicable, computer algorithm. While the block diagram suggests that a problem is not “given”, very little is said about how a problem comes to be defined as such, e.g., what simplifications and assumptions are required; what reductive and abstract methods and notions are deemed appropriate; what detail, what resolution, what confidence is demanded. The first block does not say Construct the Problem which would be more akin to what the first step is truly about. What is implied is that the problem is there at the start, out there in the world its causes to be discovered, needs to be identified, constraints to be met all waiting to be found, reduced down, and fit to an existing disciplinary mold. This is a myopic vision of the challenges engineers face. Generally they are not handed a problem, complex or simple, but must engage with others, usually, in the construction of the beast. This requires knowledge and know-how too but it is not of the same sort that figures in the abstraction and problem solving process. In 1. This makes designing an “iterative” process. John Robinson, in “Engineering Thinking and Rhetoric”, Jour. Eng. Ed., July, 1998, distinguishes between simple and compound engineering problems. His characterization of the differences between the two resonates with the distinction made here between object-world analyses and the challenges of design. Define the Problem: Cause of problem? What is need? Requirement? What are constraints? Generate & Select Possible Solutions