# Chris M. '12▾

Dec 8, 2011

## The Complexity of Simplicity

Posted in: Miscellaneous, Freshman Applicants

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.

#### Comments (Closed after 30 days to reduce spam)

Hi Chris. Great entry! I keep hoping the admissions committee has been able to see my devotion and passion, like you said, as I anxiously await EA decisions... Thanks for the cool post. Turning everything into a mathematical formula ftw! haha.
P.S. - It's smorgasbord, not smorgasborg.

Posted by: Erin on December 8, 2011

Ahh... This I strongly agree with. Reminds me of Occam's Razor

Posted by: thelittlerhoboatthatcould on December 8, 2011

The more I read about MIT, the more I want to be there. Hopefully, admissions saw my passion as well.
Unfortunately, I cannot see the formulas (stupid computer). Nevertheless, it's hard to imagine that you reduced your design to one moving part from eight moving parts. Very impressed! I'm eagerly looking forward to see the design in action on your next blog Chris.
Perhaps you could upload a video of the product instead of pictures.
See ya on Monday!

Posted by: Brent on December 8, 2011

Totally agree that simplicity is often harder than complexity.
It the images seem to be broken - seems the URL was not updated past the internal editor (showing webkit-internal-url), which makes the illustrations a little less illustrative.
I have also found this to be the case in software design - the more 'moving' parts, the most stuff to break, and deleting code always is more gratifying than writing code.
I have seen that complexity is a good way to cover up problems, while simplicity forces you to evaluate every problem.

Posted by: Iain on December 8, 2011

Great post!
Shouldn't the second equation be Sc=Pc/Pu? After all, if the understanding is complex, the more complex the problem, the more complex the solution.
Therefore, if increasing Pu is not an option, try replacing the problem with a simpler one, thereby decreasing Pc.

Posted by: Ariel J., '17 on December 9, 2011

I like all of the posts, but this is probably one of my favorites because it makes so much sense and really strikes a chord of familiarity within me.

On another note, shouldn't the first equation be from i to n, not infinity? N would be the actual number of sub-problems you have, because going to infinity implies that you have an infinite amount of sub-problems to solve before you get to the solution. Unless you mean engineering really does have an awfully large amount of problems to solve before getting to the final solution...I'm scared.

Posted by: J. Fredricks on December 10, 2011

Posted by: sujit on December 10, 2011

when do decisions for EA come out? I know last year they came out at 9pm on the 16th but what about this year?

Posted by: anonymous on December 10, 2011

I don't know when the date is, but Chris P. said they'll tell us on Monday. Also, apparently it's not the 15th.