Sunday, October 28, 2018

Engineering and the Mind's Eye: an annotated bibliography



Engineering and the Mind's Eye by Eugene S Ferguson (1972, MIT Press) is a discussion of a view on engineering that differs from the mainline education of contemporary engineers in most disciplines. It emphasizes the history of engineering in design and the inherent way in which engineering uses visual or even artistic representation to communicate and develop solutions for patrons. While focused on the physical engineering disciplines, I believe it informs an approach to software engineering that is not taught today and which is poorly understood or appreciated.

"The Secret of Design
The design of Italian fortresses illustrates a fundamental tenet of engineering--one so right and proper, so self-evident (once it has been pointed out) and now so ingrained that it has become axiomatic: Whatever an engineer may be called upon to design, he know that in order for the plans to be effective the system being planned must be predictable and controllable. The designer first defines the boundaries of the system (often involving highly arbitrary judgements), just as the fortress designer set his boundaries at the limits of cannon range. Then the permissible inputs to the system and the permissible outputs from the system are carefully determined. Nothing may cross the boundaries unobserved or unaccounted for. There is no place an ideal engineering system for unpredictable actions, either by machines or by people. Thus the assumptions and essential procedures of the fortress designer--the fortress mentality--fit naturally the needs of the modern engineering design."  p 70

This passage is pregnant with implications for application in software engineering and is just one of many passages which discuss civil engineering or other physical engineering traditions but can be mined to gain insight into how software engineering is done by contrast with how we do not follow in this tradition.

The first obvious point is how systems engineering is about the identification of system boundaries with focus on that which crosses the boundaries. This is always taught to one degree or another in a standard CS curriculum but often given only an hour, at most, in the classroom. Yet there is a great deal of subtlety in where these lines get drawn and the very central issue of figure and ground that is assumed. In the 90s a popular mantra in systems consulting was the risk/reward ratio of scoping a re-engineering effort. A large percentage of system's projects are not greenfield development but instead a re-engineering of existing function. There is benefit to the patron in the re-engineering but that benefit is tied to the scope of that effort. A small scope can have only a small benefit while a larger scope may have a larger benefit. If the relationship of cost/benefit and the risk is linear, this is an easy decision to make. But it is rarely linear and it takes a measure of educated judgement to scope the project to maximize the benefit to the final cost.

This kind of management decision crosses the boundary between the technical engineering and the project management and the organization culture and upper management.

Another insightful comment has to do with the predictability of the system. Earlier in the book the point was made that much of modern engineering has to do with the manipulation of mathematical models of the system under design. The ability to accurately model a complex physical system with math varies depending upon the system. And the arc of engineering in any discipline has been the refinement of those models, often with the insight of prior failures. Engineers have always depended upon the knowledge gained from building the scale models or even complete project based on novel ideas and then refining based on experience over time. (Tacoma Narrows is only one example). Complex physical systems are often not completely modeled by the mathematical models. Insofar as we have a solid logical model of a computer system, this would not be a problem. But at some point every computer system will interface with a human being. And our understanding of HCI is in no way modeled using a mathematical model. We simply don't have the tools to do that nor do we even know whether that would be possible.

***

We have become so accustomed to this subordination of technology to science that it is difficult to realize that the Renaissance engineer, trained as an artist and retaining the artist's use of intuition and nonverbal thought, had significant counterparts in the United States as recently as the nineteenth century. For example, Robert Fulton of steamboat fame and Samuel Morse, inventor of the American telegraph, wee both artists before they turned to careers in technology.   (p 155)

***

The Crisis in Design
In the late 1950s, the declining ability of engineering graduates to carry ut design projects was becoming painfully evident to employers and to older teachers and administrators in engineering schools.

In 1961, Pay Chenea, head of the mechanical engineering department at Purdue, observed that while the engineering sciences had developed rapidly, design had "slipped back." Perhaps that was because the "faculty of several institutions have concluded that this may be an area of knowledge that cannot be successfully taught and hence have taken steps to eliminate an experience in design from the students' program." Perhaps a better explanation of the slipping back was that given by B. R. Teare, Jr.,m dean of engineering at Carnegie-Melon University:  "Design must compete with the engineering sciences for a place in the curriculum and for academic respectability and prestige."

A 1961 report issued by a faculty committee at MIT fully justified the fears of those who saw a crisis in design. Recent graduates were criticized for "unwillingness an inability" to consider a complete design problem and for preferring to tack only the fully specified problems that could be solved by analytical methods. This tendency was more marked at the M.S and Ph. D. levels, where young engineers "feel at home in solving problems which have numerical answers--the kind of problems used in school for teaching analytical techniques." Also, these "young engineers tend to consider problems which do not involve mathematics at least at the level of the calculus as beneath their dignity--something to be turned over to a technician who [is] without the benefit of a higher education."  (pp 161-162)

***


No comments:

Post a Comment