This course serves as a bridge between single-subject content courses and students' future careers as engineers. In single-subject courses, students are expected to master specific content and methods, thereby developing critical background for their future careers as engineers. Most often, these courses consist of lectures, problem sets, and exams. This course pushes students to apply and integrate that accumulated background, and it immerses students in engineering in the full sense of the word.
This is a new experience for most students, and the project is probably bigger than anything they’ve done yet. It’s demanding, eye-opening, and exhilarating.
— Dr. Short
Students go through the engineering design process from start to finish. They search the literature, form and pursue original ideas, integrate and apply their knowledge, examine technical details, experience the complexities of engineering design, communicate and collaborate with each other, and communicate their final design in both oral and written form. Through experience, they learn a range of skills that are critical to their future success as engineers.
This is a new experience for most students, and the project is probably bigger than anything they've done yet. It's demanding, eye-opening, and exhilarating. Students have worked together on problem sets before, but they don't know what working together means on a huge project like this — and that's where the fun comes in. Students need a course like this to fully prepare for careers in engineering.
I took this course as an undergrad at MIT, and I had a blast. It was the first time that a course didn’t mean you show up, you listen to lectures, you do problem sets, and you go home. This was, you get 13 weeks. Put something together that's supposed to take a year to design. Go do it. The clock is ticking.
Students learned a range of lessons about engineering through this class. Here are two specific examples.
Dr. Short works one-on-one with a student on the nuclear engineering project. (Image courtesy of Curt Newton.)
In this class, students worked in two teams on the project. One team designed a part of the project that produced hydrogen, while the other team designed a part of the project that produced biofuels. The link between them was the amount of hydrogen being supplied to the biofuels plant. In one instance, when teams were putting things together, they were off by a factor of 10. It's no big deal, right? It's just an extra 0. It turned out to be a huge deal because the hydrogen production plant then had to scale up their process by a factor of 10, requiring a lot more energy from the reactor and hence much bigger piping from the process heat group.
In other cases, one thing would go wrong all the way at the end point of the design and the changes propagated all the way to the beginning. Students would then have to change the coolant they were using, or the power level of the reactor, or some other part of the design, because of something way downstream on the design.
In any place where the two teams didn't mesh together, the issue propagated through the entire project and the whole team felt the effect. That's where the frustration and the eventual learning of how to collaborate came in. I don't think they could have learned these lessons without the frustration.
One of the things students found surprising about this class was how many times they had to revisit the same work and the same problem. Part of that came from working together and making sure everyone's work was in line, and part of that was that if you have something this big, it has a lot of components. It's not just a problem set with an answer or an end-of-the-year design project where you design a small device and either it works or it doesn't.
With a design project, there's no real way to say that you've done it better than anyone else could have. By the end of the course, the students had analyzed all the requirements and compared the design requirements with customer requirements. They could look at a set of possible solutions and explain which were better in which situations, for what reasons, and by how much. They had to get an efficient solution, a solution that they would be willing to get up on stage and defend. That's getting a deep understanding of the problem, not just solving the problem.
I think students are often surprised to find that when they have everything designed, they're not even close to done. Then there's optimization and proving and re-optimization and re-proving and cross-checking, and there's a lot more work that goes into it once you're "finished."