Category: Engineering Curriculum

Categories
Engineering Curriculum

Benefits of an abstract engineering education

My prior post was critical of the abstraction-based, mathematics-heavy, and computation-focused eduction served up to today’s engineering students. It has been my experience has been that the most successful engineers in industrial practice are very hands-on, with years of practical experience, and insights that have little to do with academic equations. That’s not to say that the academic abstractions are unimportant, for they provide the language of discussion. An intelligent conversation about, say, a motor drive system, requires participants to understand that additional motor horsepower is not necessarily needed to produce greater output torque. (An engineer friend recently shared with me his attempt to explain this to a non-engineer boss. In the end, the boss said, “This doesn’t make any sense to me, but if you say it’s so, it must be.”)

Despite possible shortcomings in the current methods of engineering education, today’s graduates continue to be hired, and paid well-above average salaries—so employers obviously benefit from bringing on students who survive the current curriculum. Whatever modifications I might advocate for improving engineering pedagogy, I would certainly hope not to abandon these beneficial characteristics of today’s engineering programs. So what does an engineer learn from dealing with high levels of abstraction?

  • Perseverance — It often takes hours, maybe even days, to work through a single homework assignment. One has to look at each problem statement and begin trying to match the available information with potential methods of solution. Often times, roadblocks in understanding are encountered. The instructional material needs to be re-read, and re-evaluated to build a more comprehensive understanding of the solution technique. If the solution is not already known (from prior semester homework files, or found online), then a student has to at least convince themself that their path of deduction and computation is logical and rational. Shortcuts in this process are rarely rewarded in the long run, and engineering students rarely make it past their sophomore year if they haven’t acquired a healthy dose of perseverance.
  • Emotional suppression — Solving math problems is not a matter of nuance, or persuasion. It doesn’t matter how mad you get, or how optimistic you may be. Either your solution works, or it doesn’t. A successful student learns to keep cranking away at a problem until the correct solution is found, regardless of their emotional state.
  • Delayed gratification — Not withstanding the time spent working individual problems, engineers have to spend several years working on fundamentals before they can begin to solve higher-order engineering problems. Want to study photography? Grab a camera and go take some pictures. Want to be a writer? Start a blog. Want to be a civil engineer? Then expect to take four semesters of prerequisite courses to get to the point where you can begin seriously talking about bridge construction. In fact, your four years in engineering school are just a warm-up for going into industry, where you have to learn how engineering is carried out in the real world.
  • Humility — Solving complex math problems leads one to be wary of false optimism. A dropped sign, a transposed notation, a forgotten property, a misunderstood application—all can lead to an incorrect solution, even though the methodology seems correct. This aspect of the engineering education has been well-stated by Vivek Haldar:

    To be a successful software engineer (or indeed, any engineer), one first needs to be utterly and completely broken by failure. One must be so humiliated by a complex system that they give up and realize that the only chance of moving forward comes from being a supplicant to the complexity, by approaching it with humility and caution, not with hubris. You have to listen to the system, coax it into behaving. Commanding it does not work.

  • Sub-problem identification — Getting the hang of breaking complex problems into solvable sub-problems is an important engineering skill. My understanding of how this could be accomplished came in the second half of my sophomore year. No longer did I have to look for an equation or method that solved an entire problem at once; I could break the problem into smaller parts and solve the sub-problems individually. This was my first inkling that I might actually be able to “think” like an engineer.

Any other benefits to a traditional engineering education that I’ve missed?

Categories
Engineering Curriculum

Along the engineering spectrum

My prior series of posts (part 1, part 2, and part 3) proposed that a common characteristic of all engineering activity was the use of abstract models to search a solution space before implementing a new method, device, or system. Engineers fill the gap between science, which seeks to generate accurate models, and manufacturing, which aims to accurately replicate a given embodiment. Some engineers are more “hands-on” than others, so we have a spectrum of engineering activities that range from mostly abstract to mostly physical. It is this spectrum of engineering skills that I want to discuss. (Since the traditional engineering fields focus on the physical realm, I’m addressing that particular domain. However, the same spectrum issues will exist for engineers operating in alternate realms. See my prior posts for a discussion of engineering realms.)

There are many different kinds of engineers, but I’m going to constrain the conversation by dealing with just three types of engineering professionals: research, design, and production engineers.

High Abstraction

Research engineers operate at a high level of abstraction. This necessitates that they be part scientist, and part applied mathematician, as well as an engineer with knowledge of the physical world. When striving to create models that more accurately represent physical world behavior, they take on the role of scientist. In creating such models, they tend to look for general behaviors that apply to all systems, or sets of systems, rather than the idiosyncratic behavior of individual implementations.

Researcher engineers do not normally need to extend the bounds of mathematics (although some do), but must have very strong mathematical skills to create and manipulate abstract models of physical behavior. A researcher in chemical engineering might, for instance, develop a new means for causing to plastics to decay in a ecological manner. The primary focus would likely be on a model that explains the decay mechanism, rather than how the method might someday be introduced into production.

Moderate Abstraction

Design engineers bridge the gap between high and low levels of abstraction. While they are free to consider a broad range of implementation methods, they must eventually deliver a design that will produce a desired result. They use existing models to examine possible solutions, rather than launching new experimental studies.

Rather than seeking a theoretically optimal result, as the researcher might, the design engineer must settle for a practical compromise between competing interests. Experience plays heavily into knowing how much weight to give to each design constraint. A thorough knowledge of manufacturing methods is also crucial to the design engineer, as the end design must allow for robust performance, whether for a single prototype, or for a product that will be reproduced millions of times.

Low Abstraction

A production engineer worries about keeping the manufacturing line operating in a smooth fashion. There is no need to worry about the theory of how the end product operates, or what it is going to look like–those decisions have been made upstream by the research and design engineers. Instead, the production engineer is mostly a troubleshooter, waiting for a production snag to arise, then resolving the issue in a manner that keep the problem from reoccurring.

While the research and design engineers can worry about more global issues, the production engineer has to be concerned about individual elements. Specific batches, machines, and output units each give indications as to the state of the manufacturing process. Coordination of corrective efforts, mixed in with the natural stress of high-volume manufacturing, requires that the production engineer be a strong communicator.

Summary

Just as there are differences between the various realms of engineering, each engineering job requires its own level of abstraction. In my next post, I’ll write more about the skill sets needed along the engineering spectrum, and their impact on engineering education.

Categories
Engineering Curriculum

When to introduce the matrix exponential?

In the study of linear systems, a familiar relationship is the homogeneous state-space equation \dot{\mathbf{x}}=A(t)\mathbf{x}(t), where \mathbf{x}(t) is an n-vector, and A is an n \times n matrix. The time-invariant solution, (i.e., when A is a constant matrix), is \mathbf{x}(t) = e^{At} \mathbf{x}_0. When this subject is first introduced, the solution is often assumed, rather than derived.

The thinking is that since the solution to the homogeneous scalar equation is x(t) = e^{at} x(0), then students will willingly accept a matrix-friendly equivalent that solves the state-space differential equation. So the definition for the exponential matrix is given, and is shown to work for the homogeneous case:

\begin{aligned} \dot{\mathbf{x}}(t) & = \frac{d}{dt} \left( e^{At} \mathbf{x}_0 \right) \\ & = \frac{d}{dt} \left( e^{At} \right) \mathbf{x}_0 + e^{At} \frac{d}{dt} \left( \mathbf{x}_0 \right) \\ & = A e^{At} \mathbf{x}_0 + e^{At} \left( 0 \right) \\ & = A e^{At} \mathbf{x}_0 \\ & = A \mathbf{x}(t) \end{aligned}

It seems to me that this presentation sequence, however, masks what is really going on with the system; that there is an infinite recursion on the initial state, \mathbf{x}_0, that converges to a value for \mathbf{x}(t):

\begin{aligned} \mathbf{x}(t) & = \mathbf{x}_0 + A \int_0^t \mathbf{x}(\tau)\, d\tau \\ & = \mathbf{x}_0 + A \int_0^t \left[ \mathbf{x}_0 + A \int_0^t\mathbf{x}(\tau)\, d\tau \right]\,d\tau \\ & = \mathbf{x}_0 + A \int_0^t \left[ \mathbf{x}_0 + A \int_0^t \left[ \mathbf{x}_0 + A \int_0^t\mathbf{x}(\tau)\, d\tau \right] d\tau \right]\,d\tau \end{aligned}

This recursion obviously repeats ad infinitum. However, the matrix exponential can now be defined by collecting terms on the right hand side, leading to:

\begin{aligned} \mathbf{x}(t) & = \left[ \mathbf{I}_n + At + \frac{1}{2!} \left( At \right)^2 + \dots \right] \mathbf{x}_0 \\ & = e^{At} \mathbf{x}_0 \end{aligned}

Presented in this order, the exponential matrix is developed based on system response, rather than the other way around. This strikes me as being easier to comprehend than “guessing” that some seemingly arbitrary function might solve the problem. Is this conceptually easier for anyone else?

Categories
Engineering Curriculum

Career, Teaming, and Entrepreneurial Methods

Well, now that the fall semester has started at Purdue, I’m going to make an effort to post more regularly. Of course, just one post a month would be more regular than my recent performance. 🙂 Anyhow, today’s e-mail brought a brochure for a course (IE 590 & ChE 597) titled, “Career, Teaming & Entrepreneurial Methods for Engineers.” It promises to teach engineers how to:

  • Be proactive in career development
  • Develop interpresonal and professional communications skills
  • Understand large technical project management
  • Develop an awareness of the technical marketplace and the supply of technology
  • Learn entrepreneurial methods

It sounds interesting. Why isn’t this type of class required for all engineering students?

I might be tempted to take it if I could afford more time away from my dissertation. However, I can’t graduate without defending, and I can’t defend without a dissertation. And it’s difficult to teach at a leading engineering school without a PhD. So more of my future blog entries may be more related to my research (and less devoted to engineering education in general). At least until I clear the hurdle of completing my final defense.

Categories
Engineering Curriculum

A Narrower Focus

As I enjoyed lunch with a friend today, he described a teenager that he has been counseling. The young man that my friend has been advising wants to be engineer. When asked why, the teen replied that he wants “to build things.” That’s certainly why I wanted to be an engineer. It’s also why I was so frustrated in my first two years of college. I didn’t understand what possible connection all of the math and physics I was “learning” had to do with making things. My father ran a machine shop, so I knew what making things looked like. It usually didn’t involve a lot of calculus. In fact, I worked in industry as an engineer for twenty years without ever having to solve a single integral.

This doesn’t mean that I didn’t need to understand math and physics. On many occasions I approximated an integral using Riemann sums, because I understood the integration concept. However, the connection between my engineering studies and the shop floor certainly escaped me for my first couple of years in school. I know many talented young people who got frustrated with engineering and quit because they couldn’t see the relevance of the engineering curriculum. Their youthful passions “to build things” were quashed for a lack of clear and direct communication about what engineers do and how they complete their assigned duties.

As I think about the future of engineering education, it’s easy to get caught up in interesting conversations about college costs, classroom technologies, and alternative certification. However, the problem I need to focus on is that of curriculum relevance. What does an engineer need to know in order to go “make things?” How do you make that knowledge relevant to an eighteen year old student? What are the key points that every engineer should remember and understand a decade after graduation? All in all, I need to narrow my focus and concentrate on these issues.

Oh yeah, it wouldn’t hurt to get my dissertation finished, either.

Categories
Engineering Curriculum

Adding to the Curriculum

While trying to get more informed on how engineering education can be improved, I thought I’d post my “newbie” perspective on what subject material needs to be added to the core engineering curriculum. As illustrated above, there are at least six areas that I think deserve greater attention. These are, in no particular order:

  • Software Skills: As I mentioned in Programming the Physical World, I think that software skills are going to become exponentially more important in coming years. I’m not talking about knowing a particular language syntax, per se, but rather an awareness of issues such as code storage (revision control), quality assurance (unit testing), and complexity reduction (refactoring). It’s far too easy to create software that gets the job done, but leaves gaping holes with regard to access, usability, and security. Just look at the constant stream of code updates from big players like Microsoft, Apple, and Adobe—these companies have access to world-class programmers, yet there remains an unending flow of corrections to fix previously undetected errors. Just this week, Microsoft admitted to a security bug that’s been in their code for 17 years! As we start programming the physical world, it won’t just be bits and bytes that are compromised. It could conceivably be bridges and electrical stations and chemical plants that are compromised as the result of poor programming practices. As with so many things related to engineering, a small mistake can lead to disastrous results. It seems to me that an instructional program like Software Carpentry would go far in helping engineers improve their software skills.
  • Individual and Group Behavior: We train engineers to be great problem solvers, yet much of the difficulty in implementing solutions is not technical, but rather social. Further, we want engineers to operate devoid of emotion, and to think in a purely rational manner. Yet a quick glance at popular books like Predictably Irrational and Sway: The Irresistible Pull of Irrational Behavior indicates that most people operate in anything but a rational manner.  At the very least engineers should be aware of:
    1. Their own limitations in perceiving and evaluating the world around them.
    2. Human tendencies to respond in certain ways to external inputs; for example, our innate tendency to want to reciprocate favors, to be part of the majority, to be consistent in our actions, etc.
    3. Methods used by marketers and politicians to sway both personal and group decision-making.

    If engineers are going to be effective in advising society about our increasingly complex world, they need to be aware of human tendencies in evaluating information, and in responding to requests for action. I’d like to see a semester-long program like Software Carpentry address these issues. Primary texts for this class would be Influence by Robert Cialdini, and Yes!, 50 Scientifically Proven Ways to Be Persuasive by Noah Goldstein, Steve Martin, and Robert Cialdini. A text on negotiation skills might also be appropriate here.

  • Technical Communications: If the preceding class on human behavior provides the strategy for effectively communicating an engineering perspective, then this class would be focused on the technique of delivering a targeted message. Engineers need to have a sense of how non-engineering audiences process information if they are going to counter the emotional appeal of most marketing campaigns. An investigation of information graphics would include texts ranging from Tufte’s classic book, The Visual Display of Quantitative Information, to the more casual Back of the Napkin. The Challenger Incident could serve as a case study in the importance of clearly deliniating the important engineering issues at hand.

    Methods for presenting a clear, concise message would be covered, referencing texts such as Presentation Zen and slide:ology. Also included would be a discussion of presentation styles such as the Lessig and Takahashi methods, as well as the Pecha Chua and Ignite formats. An introduction to LaTeX may be appropriate as well, as few things are uglier than presentation slides showing equations that have been typeset using Microsoft products (IMHO).

  • Risk Management: It is rare in most industrial settings to find individuals who can keep up with the mathematical skills of a fresh engineering graduate. So when an engineer is asked to make a calculation, the boss rarely wants to know how the calculation is performed. Rather, the boss wants to know if a particular product or process will operate in a desired manner. However, given the variability in all materials and methods, there is never an exact answer to such a question.

    For some engineering problems, such as elevator construction, there will be a safety factor that is specified by code. However, no particular safety factor is given for most industrial tasks; an engineer must determine the appropriate safety factor for each situation. To do so effectively, an engineer must be cognizant of the risks that are inherent with his or her assumptions, and know how to convey the risk of those assumptions to others, who will likely possess less technical knowledge. This is especially critical given that all of us usually make poor estimates of inherent risk. It appears that Virginia University’s Center for Risk Management of Engineering Systems is attempting to address some of these issues.

    Update: A possible text for this material is Judgment under Uncertainty: Heuristics and Biases. Referenced in this post by John Cook.

  • Physical Problem Solving: Engineering problems would take forever to solve if each engineer had to develop their own theory of calculus. Yet we leave engineers to come up with new designs without giving them any hint as to how the work of prior generations could help them solve their problems. If the engineer doesn’t stumble upon the connection to prior work by happenstance, then each new design effort is simply an educated guess.

    Inventor Genrich Altshuller and his colleagues studied the trends found in Russian patent filings starting in 1946. They developed a theory known as TRIZ, which translates from Russian as an acronym for “the theory of solving inventor’s problems.” The TRIZ methodology offers users a means for examining “new” problems in terms of existing solutions, thus often leading to quicker results. Although much of the TRIZ theory has been extended by private firms that keep their methods close to the vest, there do exist some open-source resources for learning this approach. There are also numerous books on this subject, including one by TRIZ developer Genrich Altshuller himself. Instruction in the TRIZ method could be enormously beneficial in improving the effectiveness of tomorrow’s engineers.

  • Design Thinking: If the prior class defines how to produce a technical solution, this topic seeks to identify how to successfully implement a human solution. There is usually a large disparity between what people say they want or need, and what they actually use, do, or buy. Thus design thinking, in essence, is a focus on identifying human needs. As noted in a recent post by Stanford professor Bob Sutton, design thinking was developed by engineers. It is now being incorporated into other areas of study, including medical schools and MBA programs. However, many engineering schools fail to introduce their students to even the basics of design thinking. In addition to instructional material available from Stanford’s d.school website, there a lot of information available from the website of design leader IDEO. Perhaps books like The Art of Innovation and Change by Design could serve as reference texts.

So what is going to be thrown out of the core engineering curriculum to permit these courses to be taught? My current thought is that there must be a way to more quickly bring students up-to-speed. Perhaps the “lecture, study, homework, test” cycle of traditional education can be improved upon. If so, I bet the solution will rely heavily on the six skills areas outlined above.