FNL
HomePage
Editorial Board
E-mail FNL
FNL Archives
MIT HomePage

Teach Talk

Redefining Engineering

Warren Seering

The distinction between science and engineering is clear. "Science is the process of understanding what is. Engineering is the process of creating what hasn't been." Such descriptions have been credited to Einstein, Von Karman, and others. I suspect that few here would disagree. The processes of science yield understanding. The processes of engineering yield artifacts.

In practice, engineering and science are sometimes intertwined. This said, the meaning of the phrase "engineering science" is unclear to me. Does it describe a process? Is it a name given to engineering domain knowledge? Is it a branch of science? Most importantly for me as a member of the engineering faculty, what is the relationship between engineering science and engineering?

As I try to decipher the meaning of engineering science, a thicket of related questions appear. Are we preparing our students to be engineers, scientists, or both? How do the objectives differ for our undergraduate and graduate students? What is the role of the Scientific Method in our educational program? What is the Engineering Method? What does it mean to teach engineering?

The following assertions may bring some clarity. The engineering sciences are fields of science whose domain knowledge is central to the practice of engineering just as the biological sciences are fields of science whose domain knowledge is employed by biologists. Exercising the Scientific Method in the domain of engineering yields an understanding of new engineering knowledge. Our engineering graduate students are being taught to be engineering scientists with the ability to understand new engineering knowledge. The undergraduate educational process gives students an understanding of existing engineering knowledge and a level of competence at attaining this existing knowledge.

From the perspective of our undergraduate engineering students, the distinction between engineering and science may not be so clear. Most of the engineering coursework for our undergraduates produces understanding (we hope) rather than artifacts. Engineering education may seem like scientific discovery, because learning processes and scientific processes share the objective of creating understanding. To distinguish among the processes being considered here, we can say that:

The primary objective of our current mechanical engineering curriculum is to guide our undergraduates to an understanding of existing engineering knowledge. There is little emphasis on teaching them processes that engineers employ as they apply their knowledge. We are organized to teach the material out of context. It is understood in educational circles that knowledge learned in one context may not transfer readily to another. Therefore, domain knowledge learned in the classroom will not necessarily be available for a student to apply on the job, or even in another classroom. We've all seen evidence of this.

Our bias toward teaching domain knowledge rather than engineering process is not surprising, given the mindset of the MIT faculty as expressed in the 1997 Faculty Survey administered by the Task Force on Student Life and Learning (MIT Faculty Newsletter, October, 1997). In specifying elements that define a well-educated individual, 47% of the responding faculty listed "a fundamental base of science/technology" while only 14% listed "the ability to apply knowledge." This faculty bias leaves our undergraduates ill qualified to be engineers. Knowledge has value for engineers only when they know how to apply it, and processes for applying engineering knowledge are neither simple nor obvious.

If knowledge is most useful for engineering students when it is learned in the context of doing engineering, then the great majority of our engineering undergraduates, who will be practicing engineers rather than scientists, would be better served if we would place greater emphasis on the engineering process as part of the educational experience. What, then, is the engineering process? Some of my colleagues have asserted that the Scientific Method is the basic process of engineering. A quick review of the Scientific Method shows that this cannot be the case. The Scientific Method yields understanding through alignment of a hypothesis with observation. It does not yield decisions that define an artifact. Again with hopes of bringing clarity, I will assert that the Engineering Method has the following steps.

1. Articulate the objective to be achieved.

2. Generate a set of candidate plans for achieving the objective.

3. Evaluate each candidate in light of relevant circumstances.

4. Decide which plan is best suited to achieve the stated objective.

5. Pursue the consequences of the decision.

This Method yields an appropriate course of action if the engineering objective is to transmit torque through a shaft, to reduce the failure rate of a manufacturing process, or to increase the market share of a family of vehicles. It is applied, often recursively and at times in conjunction with the Scientific Method, throughout the pursuit of engineering goals. One can imagine an undergraduate engineering curriculum with one course on each of these five steps. An important difference between the Engineering Method and the Scientific Method is the outcome. The Scientific Method yields understanding. The Engineering Method yields a plan of action for defining an artifact, typically a device, a system, a procedure, or a service.

To this point my intent has been to suggest that study of engineering processes as well as engineering domain knowledge should be included in the undergraduate engineering curriculum. I have also proposed that integrating the practice of engineering into our undergraduate curriculum will create a more relevant context for learning the fundamentals of engineering domain knowledge, and thus will increase the likelihood that our undergraduates will be able to apply this knowledge when the time comes. Introducing engineering into the curriculum, though, will not be enough. We must also find more effective ways of teaching our students to understand engineering fundamentals, or at least not to misunderstand them.

The assignment of homework problems does have the potential to guide students toward understanding, but the process has serious weaknesses. Homework problems are more like puzzles than they are like engineering problems. As with puzzles, they have a single answer that is known in advance by the puzzle master (and by students who have taken the course previously). Typically there is a routine or algorithm that will yield the single desired solution. The students need only be able to identify the solution templates for puzzles solved previously, align the new homework puzzle with the best solution template, and make small adjustments to produce the desired answer. This pattern-matching strategy allows the students to "solve" the puzzle with little if any reliance on a solid understanding of the domain knowledge. We assign these puzzles because they minimize our workload; they are easy to grade. When students get the right answer, we can delude ourselves into believing that they understand the material. But we need only spend a few minutes talking with students individually about the course material to realize how shallow the understanding that they've gained in this way actually is. Students participate in this puzzle conspiracy because they have developed the template matching skills (or access to files of solutions) required to solve these puzzles, but they do not necessarily know how to solve engineering problems. So puzzles are what they want to see. Frequently students express serious reservations and sometimes great displeasure when faced with an engineering problem that requires clarification of objectives, synthesis, the making of assumptions, reduction to a form that can be solved, and interpretation of the result.

For the last few years I have taught engineering mechanics to our sophomores and the product development capstone course to our seniors. This has given me the opportunity to see how much of the domain knowledge that I taught them as sophomores they can apply to engineering problems as seniors. The results are predictably disappointing. Faced with the task of evaluating alternative design concepts, students in the capstone course routinely show little confidence in applying such fundamental notions as control volumes, vector sums, conservation of energy, and momentum principles. It isn't that they missed these concepts when they were taught. Most of them were able to do the homework and exam puzzles in their earlier courses. The requisite number received A's in these courses. But the type of understanding that they achieved by solving homework puzzles has not enabled them to use this knowledge when faced with an engineering problem.

This year several of our senior project groups developed human powered products. A student presenting one of the designs had calculated that about 100 watts of human power would be required to drive his device. When challenged by a faculty mentor with the fact that humans cannot be expected to generate more than 50 continuous watts of power, the student quickly replied, "That's no problem. We'll put in a transmission." The fact that this one student did not understand the implications of the first law of thermodynamics is not so disappointing as the fact that none of the other students in the section seemed at all troubled by his response. Given the limits of their understanding of the first law, I don't have much confidence in their understanding of the second.

Our capstone course is not unique in this regard. A video taken at a Harvard graduation of students and faculty who are unable to satisfactorily answer the question "Why are there seasons?" is shown in educational circles to illustrate the problem (A Private Universe, Pyramid Media, 1988). Even more troubling for us is the video from the BBC of some of our own students at MIT's graduation (wearing their robes) who, given a battery, a light bulb, and a piece of wire, don't know how to make the light bulb light (Simple Minds, BBC Education, 1994). This limitation on our students' ability to reason about basic course material is well understood by the constructivists in our schools of education. Teaching methods for addressing the problem are also well understood ("The Contribution of Constructivism," MIT Faculty Newsletter, April/May 2001; see also the nice article by Professor David Darmofal, MIT Faculty Newsletter, October/November 2002). As faculty, though, we frequently choose to believe that to teach means to reveal concepts to students in a classroom. Can we have taught the material if the students can't use it? Teaching is a profession with its own domain knowledge and processes. Many faculty do not use best educational processes because we are not familiar with them. This limitation has led some in primary and secondary education to challenge our right to claim to be educators. We have been called kings with no clothing. I find this a bit strong, but it is fair to question whether we are in violation of the American Society of Mechanical Engineering Code of Ethics which states that "a mechanical engineer will not accept a job for which he or she is not adequately prepared."

Last year in the sophomore mechanics course, I chose to give my students individual oral exams as a way to find out how well they understood the material. The results were again disappointing but not unexpected. Though most of the students had solved the homework puzzles, and scores on an earlier written exam had the usual spread, many of the students could not discuss the material with me for more than a few minutes without revealing serious conceptual misunderstandings. Not surprisingly, they were very displeased about the process. One, who did fairly well in answering the questions but who was clearly disturbed by the experience said at the end of the interview, "You didn't tell us we were supposed to understand the material. If you had, I would have prepared differently." Then in a follow-up worthy of an MIT student she said, "Now that you've changed the rules, how are you going to change your teaching?" With her beautifully simple query, she inadvertently initiated the Engineering Method by articulating the objective that we need to achieve.

Though it is only part of the solution, teaching engineering domain knowledge in the context of engineering processes is a good way to improve our students' ability to use their knowledge. Bringing engineering processes into the classroom, though, is "messy." Employing the Scientific Method in pursuit of understanding of engineering domain knowledge should yield essentially the same result for everyone. Thus it is comparatively easy to set expectations and to evaluate against them. Exercising the Engineering Method can produce as many results as participants. Some results will be apples; others oranges, making evaluation time-consuming and difficult. It is no wonder that our faculty are not rushing to bring engineering into our courses despite the potential benefits of doing so.

It is fair to ask, "Do we need to introduce this complexity given that our graduating students will primarily be responsible for the analyses associated with Step 3 of the Engineering Method?" Many of the homework assignments throughout our core courses are already designed to emulate pieces of this step. I would say that these emulations are to engineering what free throws are to basketball. Imagine a coach who prepared his basketball team for the season by having them only shoot free throws at every practice. Among the justifications for this coaching strategy might be the following: The task of shooting free throws is well posed and easy to assign and evaluate; basketball players must be good at shooting free throws; shots taken during a game are free throws to first order; the rest of the game is a straightforward extension of making free throws and can best be learned by experience in a game situation. How will these players feel when the game starts?

While few of us would elect to play for this team, we routinely assign our students to it. When we lead them to believe that doing engineering means calculating answers to well posed questions, we paint a very misleading picture. Engineering is a contact sport. It is played on a very competitive playing field by aggressive, hard-hitting, and highly motivated members of opposing teams. There are winners and losers. Big money is involved. People get hurt. Successful teams have star players who are richly rewarded. Winning requires talent, commitment, shrewd strategy, and players who can perform their roles under pressure and in well-practiced coordination with their teammates. Having people on the team with a good base of engineering domain knowledge helps too.

A successful engineering team is made up of players with various skill sets. Engineering graduates who choose to build their careers on conducting engineering analyses fall into the industrial category of "functional engineers." They are complemented by the "systems engineers" who are expected to be responsible for synthesis and system integration. In our senior capstone product development course we see that roughly equal numbers of our students are inclined toward each of these two categories. Successful product development organizations must include members of each. Then there is a third group of students who are good at both functional and systems assignments and who enjoy both. At MIT we call these folks the "system architects." They are on track to be the industry technical leaders. A large fraction of our seniors are members of this group. Our curriculum, which now primarily serves the first category of students, should be redesigned to better educate the students in each of these three categories.

So is this another attempt to introduce more material into a four-year undergraduate curriculum, opening the fire hose valve even further? (I find use of this metaphor and its accompanying imagery to be unfortunate. It implies that those who would control the valve don't understand the physics of impedance matching. It's almost as bad as the MIT school song which celebrates the propensity to "demolish forty beers.") In fact, I would propose something quite different. Herb Simon has hypothesized that a minimum of 10 years is required for a practitioner to acquire enough "chunks" of knowledge to qualify as an expert in a given field (Sciences of the Artificial, MIT Press, 1996). We should set as our academic goal to have our students qualify as expert engineers by age 30. This gives us roughly a dozen years to cover the necessary material. Since about half of our undergraduates go on to earn Masters degrees, this on average makes us responsible for about five of the years, while our industrial colleagues, who presumably share our goal, are responsible for the others. In this thought experiment I am not considering those undergraduates who will go on to earn Ph.D degrees and become practicing engineering scientists, because their numbers are small. This is not to say that they would not be well served by the curriculum here envisioned.

The task in front of us, then, is to allocate the teaching responsibilities for both domain knowledge and engineering processes among the academic and industrial educators. This will have to be a strongly collaborative effort. MIT, with its extensive network of industrial partners, is in an excellent position to lead it. There should be no preconceived notions about how the teaching of knowledge and of processes should be distributed, about the sequencing of industrial and academic experiences, or about how the academic and industrial educators will interact or even where they will reside. Because our students are being prepared for life-long learning, there should be no rush to cover all the domain knowledge in the first few years. The heavier load will rest on the shoulders of our industrial colleagues, as they have to date been less inclined to see themselves as providing a structured educational experience to these engineering experts-in-training. There will be plenty of learning on all sides as we each work to understand, appreciate, and over time respect the capabilities, limitations, and motivational structures of our two cultures. The alternative is to stay with the existing 12-year plan. I suspect that leaders in engineering education will find a way to do better.

FNL
HomePage
Editorial Board
E-mail FNL
FNL Archives
MIT HomePage