Categories
Engineering Roles

The Marshmallow Challenge

Ever hear of the “Marshmallow Challenge?” Small teams of individuals are given the following assignment: use twenty sticks of uncooked spaghetti, one yard of masking tape, and one yard of string to construct the tallest possible free-standing structure that supports the weight of a marshmallow. Most people assume that since a marshmallow doesn’t weigh much, it shouldn’t significantly affect the support structure. Of course, even a small mass can produce structural failure when placed atop a long unsupported column.

So what profession does best at this task? According to Tom Wujec, a Fellow at software company Autodesk, the tallest structures are built by engineers and architects. They consistently outperform similar teams of lawyers, business school students, or corporate managers. This is not an unanticipated result, as we expect our engineers to know something about static structures. However, it is rather surprising to learn that youngsters, even kindergarten students, do far better than most adults—kids are simply not afraid to repeatedly fail as they search for an approach that works. (You may discover more about this learning exercise at MarshmallowChallenge.com).

Two insights come from this anecdotal report of group behavior. First, that engineers have been trained to think in a manner that is distinctly different from those in other professions. Second, that repeated rounds of prototyping and evaluation may be an effective means for dealing with the messy, unstructured, uncertain problems that engineers frequently encounter.

Categories
Engineering Revision

Programming the Physical World

One of the first articles that inspired me to start this blog was an article by Greg Wilson stating

Instead of software design becoming more like “real” engineering, we’re about to see the latter become more like the former.

To see what he considers “real” engineering, we need only reference his post of two weeks later, Without the Hot Air, in which he notes that

…almost none of what we call “software engineering” is actually engineering. I’ve worked with enough civil, mechanical, and electrical engineers to know how important back-of-the-envelope reality checks are to their disciplines. Other than figuring out how many servers you need to meet a service level agreement, I don’t know if such reality checks are even possible for software construction.

Having identified a fundamental difference between software and engineering design, Mr. Wilson correctly predicts (IMHO) that “real” engineers will inevitably become more like software designers in the future, rather than visa-versa. This will occur, he surmises, because new manufacturing methods, such as rapid prototyping and desktop manufacturing, can be manipulated via easily modified code. In comparison, traditional manufacturing methods require slow and costly changes to molds and tooling. As a result, future engineers looking to optimize mechanisms and processes (beyond the level possible with mass production) will increasingly turn to these newer technologies. In turn, they will need much stronger software skills, and will therefore turn to their software-centric colleagues for advice.

Five years from now, I predict that software designers who’ve been griping about never being given enough time or enough respect will be on the lecture circuit teaching their ID and IE counterparts how to be agile, live with chaos, and cope with design cycles measured in hours rather than months.

From what I’ve seen as a (rather elderly) grad student over the past five years, the programming skills of many engineering students are sorely lacking. I’d venture to say that the majority of mechanical engineering grad students with whom I’ve worked have no idea of how to use version control, or how to write a unit test. I am acutely aware of how easily a small programming error can alter the results of my research, and I suspect that a great many published articles unknowingly rely on faulty code.

Since I am studying in the area of feedback control, much of my programming work is in Matlab. Not a difficult language, and a heck of a lot easier to get started with than Java or C++. Still, while grading homework for an introductory grad-level controls class, I’ve come across some truly awful programming practices. This is not the fault of my fellow students. Engineering is not an easy discipline, and there never seems to be enough time to adequately cover the existing curriculum. As a result, engineering students are often never been exposed to the finer points of software construction. In many cases, programming skills are assumed but never taught—students are simply given a handout or two and expected to come up to speed on their own.

It would appear that Mr. Wilson has already recognized many of these same problems. He champions the Software Carpentry program, an effort to improve the software literacy of scientists and engineers. It is based on Python, rather than Matlab, but could probably be ported to a new language with few technical difficulties. (Finding the time to prepare for twenty-five hours of instruction is likely to be a much larger problem.) In any case, courses like this need to be a part of every engineering curriculum. Much of the physical world is going to be programmed, rather than fabricated, in the coming years.