The Complexity of Simplicity by Chris M. '12

 

Did you know the soda can top (or “pop” can for those of you so inclined) took ~5 years to perfect and develop? And look at it. It’s simply a tab on a lever that punches out a precut piece of aluminum. It’s hard to imagine a simpler mechanism. And yet, to get that simple took an enormous amount of work.

In fact, this “simplicity follows complexity” idea is one that I’ve learned more and more throughout my time here at MIT, and particularly through one of my favorite classes, 2.009. (As an aside, that last half of the sentence was difficult to type given that I’m averaging 12hrs a day in lab with at least another 4 spent on work for that class alone, but if I’m honest with myself it’s still true).

I’ve learned that in engineering, it’s not that difficult to design individual solutions to all your design criteria, and then your proposed solution is just the superposition of all the little solutions. It’s not that hard to make a design more complex by just solving all the little sub-problems and summing them up. To express it mathematically (because there’s literally nothing I can’t turn into a formula):

 

 

Where S is your solution to a problem, pi is the ith particular subproblem, and s() is the solution to any particular problem.

 

But it turns out that the best solutions/products/designs are those that are butt-kickingly simple. The sort that make you think “that’s it?”. The kind that make you feel like anyone could do them. Those are the hard ones.

This I understand firsthand while exploring the mechanism for my 2.009 project (whose final presentation I will be in part presenting on Monday, so that’ll be a fun blog). In a nutshell, I’ve been working with my team to try and figure out a way to dispense helmets reliably and one at a time. The first proposed solution we had was enormously complex, but plausible given what we’d learned. We had four bar linkages, ratchets, pulleys – the whole MechE toolkit coming out. But in designing it in Solidworks, we discovered it was incredibly difficult to make work correctly, so we abandoned it for a much simpler mechanism. This we all felt pretty good about, until we tried to start building it and learned it was essentially impossible to implement given our constraints. So I worked with a small subset of our team and tried to find alternatives. A simpler solution was found and decided to go for that.

But once again, it was too complex. This loop repeated for a while until the eureka moment occured and we managed to reduce our mechanism from around 32 parts, with 8 moving parts in perpendicular planes, to just 4 parts, one moving, all in the same plane. And the thing works beautifully and reliably (I’m hoping I’ll get a patent out of it, but that’s another topic).

One of my teammates was commenting on how frustrating it was to get that solution after all the design and iteration we had, but that’s when I realized we HAD to go through that. Otherwise we never would’ve understood the problem with the depth necessary to see the simple solution. Turns out, problems require a complex understanding to yield simple solutions, and vice versa. Or, to express it mathematically:

 

 

 

 

Where Sc is the solution complexity and Pu is the problem understanding.

 

And that’s because it’s not until you really understand all the interfaces that you can see the nonlinear and coupled solutions. The ones where you say “yeah Sx wouldn’t solve Px, and Sy wouldn’t solve Py, but Sx + Sy solves Px, Py, and Pz which wasn’t even a design criteria!”. That’s where the innovation is, in seeing those solutions that aren’t algorithmically generated, the ones where either of two mutually exclusive extremes are non-ideal and the optimum solution is some tradeoff. THAT’S what engineering is all about. That’s why you study your brains out trying to understand how everything works and in what ways you can solve problems, because it’s only after that visceral understanding of the whole system that you get a unified, elegant solution.

And looking back, I think that’s something MIT looks for in their admissions decisions too. It’s easy to think that the best candidate is the broadest and deepest one; the stereotypical encyclopedia of extracurricular activities and good grades. But what’s more compelling than a laundry list of sub-achievements are the ones that REALLY define you. The ones you’re passionate about and interested in. Those are the ones to express in your application because they show a focused, concise portrait of yourself.

And even outside of applications and engineering, I think the principle applies to life in general (at least as much as my admittedly limited and naive experience in life has been). A simple, clear purpose seems preferable to a smörgåsbord of roles, but knowing what that purpose is requires a very deep understanding of what you want and why it’s more important than other things you want.

So in a very literal way, engineering is my life, and with remarkable overlap the lessons I learn about being a better engineer translate to making me live a happier life (well, eventually. This sleepless streak of a week is getting old). MIT is truly an incredible place to be and learn.