Skip to content

lorin/eng-qua-eng

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

8 Commits
 
 

Repository files navigation

Thoughts on engineering by engineers

A collection of writings by engineers about engineering.

What Engineers Know and How They Know It (Vincente)

This view of technology-and hence engineering-as other than science accords with statements sometimes made by engineers, such as the following by a British engineer to the Royal Aeronautical Society in 1922: "Aeroplanes are not designed by science, but by art in spite of some pretence and humbug to the contrary. I do not mean to suggest for one moment that engineering can do without science, on the contrary, it stands on scientific foundations, but there is a big gap between scientific researh and the engineering product which has to be bridged by the art of the engineer." The creative, constructive knowledge of the engineer is the knowledge needed to implement that art. Technological knowledge in this view appears enormously richer and more interesting than it does as applied science. (p4)

Engineering can, in fact, be defined in terms of these ends, as in the following quotation from another British engineer, G.F.C. Rogers:

Engineering refers to the practice of organizing the design and construction [and, I would add, operation] of any artifice which transforms the physical world around us to meet some recognized need. (p6)

Since calculation of practical viscous flows was beyond the reach of theory in the 1930s (difficulties exist even today), profile drag and other aerodynamic characteristics of airfoil sections had to be found by testing wings in a wind tunnel and subtracting out the calculated plaform effects. Development of airfoils was thus largely an empirical activity (p20).

If, with philosopher Philip Rhinelander, we take wisdom to be "the art of making correct decisions on insufficient evidence, under conditions of uncertainty," then good design judgment clearly qualifies as a form of wisdom. (p46)

Functional failure, presumptive anomaly, and the need to reduce uncertainty in design thus appear as three distinct, if often concurrent, driving forces (or sources) for the growth of engineering knowledge (p47).

A pilot and aircrqaft, taken together, form a single dynaic system, with feedback loops to the pilot via the feel of the cockpit controls plus cues from instruments and from vehicle orientation and acceleration. The pilot is a dynamic part of this closed-loop system (to use modern terminology) and sense him- or herself as such. (p76)

The background for this reversal (that is, the quarter century in which the aeronautical community was blinded by concern for the long-period oscillation) provides a cautionary example of how preconceived, uncritical use of mathematical theory can mislead in practice. (p94)

The history of flying qualities also illustrates what Constant calls "traditions of practice" in technology, which he defines as "conventional system[s] for accomplishing a specified technical task." (p106)

Finally, some remarks about the consensus on stability in the 1920s, which epitomizes the essentially engineering nature of the flying-quality work. The conclusion that airplanes ought to be inherently stable but not too much so was a judgment rendered, not from careful delibration by an individual or individuals, but more or less instinctively by the flying-quality community as a whole. It was arrived at gradually in the first three decades of the century by relating the growing, objective knowlege of stabilty and control to the similarly growing body of subjective piloting experience with expanding flying tasks. The otucome was a balance, or tradeoff, between conflicting requirements—control versus stability—of a kidn that engineers often find necessary. Teh necessity, here, however, did not arise, as engineering tradeoffs often do, for economic reasons. Neither did it derive, of itself, from purely theoretical requirements—it came into being because of the practical needs and limitations of teh human pilot. The balance therefore could not have been achieved on purely intellectual grounds and without extensive flight experience. It summarized a practical design judgment (based in this case on subjecive opinion) of a sort that cannot be avoided in engineering. Achieving such judgment—and these remarks apply equally to the flying-quality work as a whole—involved elements that can properly be regarded as science (e.g., teh analysis of dynamic response by applied mathematicians). Predominantly, however, it called for a great deal more than simply the applicaiton of scientific knowledge and principles. It required a complex interaction of intellectual and experiential elemntes reacting to and going on within a context of practical design demands. This "great deal more" provides evidence, if such is still needed, of the epistemological difference between applied science and engineering. (p107)

The Mathematical Disposition of Structural Engineers (Gainsburg)

https://www.jstor.org/stable/30034962

The most intractable problems I observed stemmed from what I came to see as the fundamental problem of structural engineering: that the phenomena at the center of the engineers' work (the structures and their behaviors) were nonexistent or inaccessible. Three of the observed tasks concerned buildings that did not yet exist; the fourth was part of the evaluation of an existing building to which the engineers' only access, essentially, was 50-year-old drawings. This fundamental problem distinguishes the activity of structural engineers (and other design workers) from that of scientists, who usually have empirical data for the phenomena they study.

Structural engineering is a bootstrapping process. The engineer makes initial rough design assumptions to get started, then design and analysis inform each other as they converge to a final state through repeated iterations. Unfortunately, an empirical test of the "correctness" of the design or is rarely possible (short of waiting to see if the constructed building ultimately performs or fails; even then it may be impossible to trace failure back to a specific design or analysis solution generated perhaps decades earlier).

Students and engineers must justify their results, but their proving practices diverge as well. In school mathematics, starting assumptions (the givens of the problem and mathematical axioms and postulates) are accepted as true-the student need not establish their accuracy-and the real challenge is to construct a chain of logic linking them to the desired end statement. For the engineers, many of the starting assumptions-simplifications of the design and environmental conditions-were not established, and identifying appropriate ones and justifying their accuracy were typically the main challenges. Once the assumptions were set, proving that the design was structurally sound was usually mathematically trivial, requiring little more than performing a calculation whose steps appeared in a codebook or had been memorized, or activating the "solve" function of a computer program. Also, the engineers practiced other forms of justification besides mathematical proof. That a design satisfied adeductive argument for structural soundness was insufficient rationale for building it. It also had to be justifiable on the bases of feasibility, available materials, labor capacity, budget, and time, as well as on the less tangible but arguably more crucial grounds that the design solution and the method that yielded it made sense and "felt good" to the engineer.

Underlying these and other mathematical practices I observed was a phenomenon that the engineers referred to as "engineering judgment," which they found hard to articulate even though they all seemed to know it when they saw or used it. In my analysis, engineering judgment comprised the decisions engineers made about resources and methods and their relative statuses. The engineers admired engineering judgment, recognizing it as a commodity hard-won over years on the job. In some sense, the engineers equated engineering with the exercise of engineering judgment; at least, what inspired engineers to identify colleagues as expert had more to do with the ability to make judgments than to apply and perform mathematics. Engineering judgment covered more than the use of mathematics, but it subsumed decisions about mathematical methods and results. Therefore, understanding the mathematical disposition of engineers first requires an analysis of the broader phenomenon of engineering judgment.

Engineering judgment often entailed anonmathematical decision about a situation that could not be adequately mathematized; that is, it sometimes replaced mathematical resources, bridging unmathematizable gaps in the analytic process. Engineering judgment and proof were in some sense opposites. Proof was mathematical and deductive, and where proof was possible, judgment was unnecessary. Of course, engineering judgment played an important role in proof by providing underlying, unprovable starting assumptions or by assessing how realistic were a proof's conclusions. Conversely, however, engineering judgment had no recourse to proof; it could not be verified (without, as mentioned earlier, waiting years for the building to be constructed and to fail). Finally, engineering judgment only concerned predictions about structural behavior, environmental conditions, or other physical phenomena. It did not cover judgments about procedural, political, managerial, or organizational expediency.

Even when mathematical analysis "proved" a design sound, the engineers used judgment to make a final call on the reasonableness of the analysis or design. That judgment could adopt a higher, more conservative standard than the proof or a looser one. The resources the engineers drew on to judge the soundness of their methods, behavioral assumptions, and solutions could be theoretical, mathematical, physical, visual, intuitive, social, or experiential.

Decisions about the precision of a value or the resolution level for analysis pervaded the observed tasks. This was an unavoidable consequence of the fact that the structures being analyzed only existed via representations-drawings or computer models-that were necessarily simplified and approximate. The constraints of time and cost further militated against precision and highly articulated analytical methods. At times, especially early in a project, anything beyond a rough estimate was inappropriate and useless.

Another critical kind of judgment the engineers had to make was whether to repair an unacceptable analytic result by modifying the design or by changing the assumptions underlying the mathematical model. Modifications to analytically unacceptable designs invariably add size, weight, and cost, so are undesirable; yet, altering the model to yield a more favorable result risks inaccurately representing the structure and its behavior and obscuring potential failure.

Judgment about models could be further complicated when the models were embedded in technological tools that made the mathematical methods and assumptions less transparent or manipulable.

Despite the deductive nature of mathematical proofs, the engineers did not automatically assign them the power of final authority. Aware of the uncertainty of the underlying assumptions (and the possibility of calculation error), the engineers crosschecked mathematically derived results against other criteria, as in the previous episode, and frequently rejected them. On occasion, they even rejected proven results that they felt were deductively sound, because they were impractical. In these cases, the engineers relied on judgment to convince themselves that overriding the proof would be safe and justifiable.

Revisionism may be denounced by historians, but it is key to the successful accomplishment of engineers' work. The information they convey in calculation packages and presentations enables external communication, evaluation, future changes, and accountability, where a true rendition of the process would merely obfuscate. This final, clean, mathematical rationale is usually generated after the fact and, as such, recalls the JPFs' post hoc mathematical rationalization as well as a related phenomenon among academic mathematicians, who consider the formal, polished, linear argument-their finished product-to be the "real math," whereas the informal, subjective, messy process that generated it goes unacknowledged and undocumented.

Kevin claimed he could analyze today's projects entirely with these approximate methods, but industry norms oblige him to use computers. He admitted to using computerized analyses, post hoc, to justify solutions he had attained using "classical" (approximate) methods:

Practically speaking, could Iget it through a city building department? No.... Could I get it through a peer reviewer? No. Everyone in the industry believes in computers. So the issue for me, the challenge, is to make the computer come up with the right answer. I use all the classical methods to figure out whathe answer ought to be, and then I use that to figure out exactly how I'm going to arrange my model.

(According to Vick [2002], Kevin's ability to jump to an obvious solution and use formal analysis later to confirm it is a hallmark of engineering expertise).

Indeed, characterizing the role of mathematics ineveryday structural engineering work is complicated. When directly asked how they viewed the role of mathematics in their work, the engineers repeatedly invoked the metaphor of a tool. For them, mathematics, like other tools of their trade, was necessary but not sufficient; their work required it, but its use, in turn, required judgment. The ambiguous status of mathematics was the naturally ambiguous status of any essential tool. One cannot build a house without a hammer, so the hammer is eminent, but it would be ludicrous to equate house-building with hammer-using and equally inaccurate to equate structural engineering with mathematics-using.

The Civilized Engineer (Florman)

Strictly speaking, the engineering profession came into being in the eigteenth century when science was first applied to the solution fo technical problems. But by adhering ot such a standard-by insisting that without scinece there is no engineering-we would exclude from our family tree many geniuses, from the builders fo the pyramids to the inventors of the steam engine, and this we refuse to do. (p26)

No matter how closely modern engineering becomes idetnified with science, no matter how electronic or theoretical its practice, no matter how much a group enterprise it may be, the end product of which seems remote and abstract, it can never be-should never be- severed from its origins in craftsmanship (p29).

In 1805 a noted French architect announced that "in order to probe the solidity of buildings, the complicated calculations, bristling with figures and algebraic quantities, with their 'powers,' 'roots,' 'exponents' and 'coefficients' are by no means necessary (p46)

In 1822 Thomas Tredgold, a celebrated British engineer who had worked his way up from journeyman carpenter, observed that "thes ability of a building is inversely proprtional to the science of the builder." (p46)

When, in 1858, W.J.M> Rankine of Scotland issued his famous and widely used Manual of Applied Mechanics, he sought to put an end to the deplorable "separation of tehoretical and practical knowledge." Yet as late as 1872 the author of a Civil Engineer Pocketbook stated that he would not refer to Rankine or other exponents of theory because theya re "but little more than striking instances of how completely the most simple facts may be buried out of sight under heaps of mathematical rubbish." (p46)

There are those today who see technological advance in terms of scientific genius, as if engineering were simply the gross application of sublime theory. At the other extreme are the vociferous supporters of hands-on ingenuity. (p46)

Some historians of technology take pleasure in crediting scientific advance mostly to craftsman—to the lens-grindres and instrument-makers, to the people of the forge and workbench. These historians make the point that without instruments—from telescopes to atom-smahers—thre would be precious little science. (p46)

In addition to the crucial rule of insturments there is also the tenacious work of the engineering expreimenter—the tinkerer, if you will—that often turns up new facts and relationships long before they are scientifically understood. Aircraft, rocketry, turbines, and semi-conductors are just a few of the many fields in which engineering has led and science has followed. (p47)

As for engineering, let us conclude once and for all that it is a blend of art, craft, and science (p48).

The tradition of government support for engineering survived the French Revolution. In fact, it was the revolutionary government, in 1794, that established the Ecole Polytechnique. That institution, soon to become world renowned, opened with four hundred students and boasted on its staff the noted mathematicians Lagrange and Laplace. A competitive examination, based chiefly on mathematics, dictated admissions. Out of this institution, and others of its kind, there evolved a technocratic elite that has ever since played a prominent role in French affairs. (p49)

John Smeaton, builder of bridges, harbors, and lighthouse, began to call himself a "civil engineer" around 1750. THe term was intended to rid his profession of the disagreeable association with military affairs. (p51)

While practically all British engineers continued to be trained by apprenticeship—the only university chairs of engineering were at Glasgow, Edinburgh, and University College in London—the concept of the French polytechnique was taking hold throughout a technologically resurgent Europe. (p54)

Britain—fountainhead of teh Industrial Revolution, home of Telford and Rennie, giants of bridge building; Brunel, conceiver of steamships; Stphenson, father of locoomotives; the native land of Smeaton, Watt, and McAdam—had forfeited forever in preeminence. The very independence of its institutitions, including the apprenticeship practices of the engineers and their societies, had impeded the requisite cooperative national effort. Not until 1889 did Parliament provide substantial funding for technical education, mainly through grants to city universities. Cambridge and Oxford followed reluctantly. (p54)

On the North American continent, technology evolved out of hte needs of frontier living. Tools and techniques were brought from Europe, but the relative isolation and the immediate problems of pioneering early encouraged the flowing of "Yankee ingenuity." Professional engineering was virtually non-existent. (p55)

These ex-military engineers were useful, but the rapidly developing nation clearly needed civilian engineering schools. The example of Europe was not lost on intelligent observers, although as in England, the traditional universities were hostile to the concept. So were most of the practicing engineers who themselves had been trained in the field or in the shop. (p56-57)

In 1870, only one in nine American engineers was a college graduate, and as late as 1916, incredible as it may sound, the figure was only about one in two. In many quarters, the school-taught engineers were regarded with suspicion by the old-timers (p58).

Engineers walked willingly into the corporate jaws, entranced not only by attractive salaries and technical challenge, bu talso by visions of bringing "efficiency" to factory and office. In the current era of prestigeous business schools we tend to forget the brief but intense passion with which engineers claimed management as their own. Around the beginning of this century, Frederick W. Taylor, a mechanical engineer from a well-to-do Philadelphia family, studied the work habits of factory personnel and proposed methods of maximizing production. Known first as the "Taylor System," these ideas were disseminated broadly as "human engineering," "industrial engineering," and "scientific management." FOr a few yeras this new specialty—remembered today chiefly for its time and motion studies—achieved great popularity. But labor groups resisted what they considered to be an exploitive approach, and many engineers regarded the movement as a perversion of engineering methodology. BY 1916 Taylor's methods were banned in governemnt-funded operations and the vogue quickly dissipated. Nevertheless, engineers continued to play a role as planners and overseers of technical work. A course called Engineering Administration was established in M.I.T. in 1913. In 1932 this specialty became a separate department in the School of Engineering. in 1952, however, the department was transmuted into an independent School of Industrial Management. Today the growth of business administration as a sepaerate discipline has served to draw a line buetween engineering and management, though the dstinction can never be absolute (p62).

Akin's Laws of Spacecraft Design

Excerpted from David Akin's website: https://spacecraft.ssl.umd.edu/akins_laws.html. These are the ones most relevant to software engineers.

Design is an iterative process. The necessary number of iterations is one more than the number you have currently done. This is true at any point in time.

Your best design efforts will inevitably wind up being useless in the final design. Learn to live with the disappointment.

Not having all the information you need is never a satisfactory excuse for not starting the analysis.

When in doubt, estimate. In an emergency, guess. But be sure to go back and clean up the mess when the real numbers come along.

Sometimes, the fastest way to get to the end is to throw everything out and start over.

There is never a single right solution. There are always multiple wrong ones, though.

(Shea's Law) The ability to improve a design occurs primarily at the interfaces. This is also the prime location for screwing it up.

Past experience is excellent for providing a reality check. Too much reality can doom an otherwise worthwhile design, though.

A bad design with a good presentation is doomed eventually. A good design with a bad presentation is doomed immediately.

(Larrabee's Law) Half of everything you hear in a classroom is crap. Education is figuring out which half is which.

When in doubt, document. (Documentation requirements will reach a maximum shortly after the termination of a program.)

The schedule you develop will seem like a complete work of fiction up until the time your customer fires you for not meeting it.

It's called a "Work Breakdown Structure" because the Work remaining will grow until you have a Breakdown, unless you enforce some Structure on it.

(Varsi's Law) Schedules only move in one direction.

(von Tiesenhausen's Law of Program Management) To get an accurate estimate of final program requirements, multiply the initial time estimates by pi, and slide the decimal point on the cost estimates one place to the right.

(Atkin's Law of Demonstrations) When the hardware is working perfectly, the really important visitors don't show up.

(Patton's Law of Program Planning) A good plan violently executed now is better than a perfect plan next week.

(Roosevelt's Law of Task Planning) Do what you can, where you are, with what you have.

(de Saint-Exupery's Law of Design) A designer knows that they have achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

Any run-of-the-mill engineer can design something which is elegant. A good engineer designs systems to be efficient. A great engineer designs them to be effective.

(McBryan's Law) You can't make it better until you make it work.

There's never enough time to do it right, but somehow, there's always enough time to do it over.

You really understand something the third time you see it (or the first time you teach it.)

The Reflective Practitioner (Schön)

Chapter 6: Reflective practice in the science-based professions.

But for all of their complexity, these studies still treat the process of clinical diagnosis as a mapping of cues in the present situation to the clinician's theories of disease and methods of treatment. If we turn from the model of Technical Rationality to the actual practice of science-based professionals, however, it is clear that technical problem solving is a radically incomplete description of what engineers, agronomists, and physicians actually do.

Faced with unexpected and puzzling phenomena, the inquirers made initial descriptions which guided their further investigations. Where do such descriptions come from? They are, at least on some occasions, outcomes of reflections on a perceived similarity, a process which in the previous chapter I called seeing as.

Kuhn calls such processes "thinking from exemplars."

Paintbrush as pump is an example of what I mean by a generative metaphor.

What makes the process one of metaphor making, rather than simply of describing, is that the new putative description already belongs to what is initially perceived as a different, albeit familiar, thing; hence, everything one knows about pumping has the potential of being brought into play in this redescription of painting.

Thus in technological development as in scientific research, inquirers can sometimes figure out how to solve unique problems or make sense of puzzling phenomena by modelling the unfamiliar on the familiar.

But the idea of reflection on seeing-as suggests a direction of inquiry into processes which tend otherwise to be mystified and dismissed with the terms "intuition" or "creativity," and it suggests how these processes might be placed within the framework of reflective conversation with the situation which I have proposed as a partial account of the arts of engineering design and scientific investigation.

What the students seem to be learning was, as Aida said, to take initiative in solving problems for themselves, to be skeptical of outside authority, to settle disagreements by experiment. But they may have been learning more than this.

These students, at any rate, seemed to be learning to model the unfamiliar on the familiar and to reframe their questions around the changes which resulted unexpectedly from their actions.

Nevertheless, as he became more fully aware of the methodological difficulties in constructing the model and of the dilemmas of implementing it, he was led to restructure his image of intervention. It would not be outside experts but community members themselves who would use the nutrient flow model idea to diagnose their own malnourishment problems and design their own interventions. With this change, community learning became an objective equal in importance to the reduction of malnourishment. And as a consequence, community members—who might have figured as parts of the social context of technical practice—became problem-solving agents.

As Wilson sought to create at the Hogar the conditions for a Cogwheel Experiment on malnourishment, he had to frame and reflect on a new problem, that of involving and guiding the community members he wished to adopt as co-inquirers.

Engineering and the mind's eye (Ferguson)

The scientific age too readily assumes that whatever knowledge may be incorporated in the artifacts of technology msut be derived from science. (xi)

Pyramids, cathedrals, and rockets exist not because of geometry, theory of structures, or thermodynamics, but because they were first pictures—literally visions—in the minds of those who conceived them.

On Line and On Paper: Visual Representations, Visual Culture, and Computer Graphics in Design Engineering (Henderson)

TBD

About

Engineering as described by engineers

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published