The Complexity of Simplicity

The Complexity of Simplicity 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. Its simply a tab on a lever that punches out a precut piece of aluminum. Its 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 Ive 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 Im averaging 12hrs a day in lab with at least another 4 spent on work for that class alone, but if Im honest with myself its still true). Ive learned that in engineering, its 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. Its 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 theres literally nothing I cant 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 thats 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 thatll be a fun blog). In a nutshell, Ive 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 wed 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 (Im hoping Ill get a patent out of it, but thats 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 thats when I realized we HAD to go through that. Otherwise we never wouldve 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 thats because its not until you really understand all the interfaces that you can see the nonlinear and coupled solutions. The ones where you say yeah Sx wouldnt solve Px, and Sy wouldnt solve Py, but Sx + Sy solves Px, Py, and Pz which wasnt even a design criteria!. Thats where the innovation is, in seeing those solutions that arent algorithmically generated, the ones where either of two mutually exclusive extremes are non-ideal and the optimum solution is some tradeoff. THATS what engineering is all about. Thats why you study your brains out trying to understand how everything works and in what ways you can solve problems, because its only after that visceral understanding of the whole system that you get a unified, elegant solution. And looking back, I think thats something MIT looks for in their admissions decisions too. Its easy to think that the best candidate is the broadest and deepest one; the stereotypical encyclopedia of extracurricular activities and good grades. But whats more compelling than a laundry list of sub-achievements are the ones that REALLY define you. The ones youre 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 its 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.