[Potential] Innovations in Teaching: Design

I have taught a mostly graduate student focused course on Precision Instrument Design for 4 of the last 5 years. This year, I have formally opened the course to undergraduate students seeking to learn this topic. We have limited options in this space so I think it can be a very useful course for students at any level interested in doing practical engineering work. In addition to having a student audience with varying levels, I also have this course cross-listed between Mechanical Engineering and Optics, which are the two academic departments that my position currently splits. However, given the content of the course, I usually have a cohort of Biomedical Engineering graduate students whose sub-discipline is in medical technology. In the past, I have had electrical and chemical engineering students as well. This is basically a long-winded way of saying my course audience has grown very diverse and I find it taxing to structure this course that does not bias one discipline too heavily. Moreover, I have been mulling two fundamental questions: 1) how can multi-disciplinary design be effectively taught to a diverse class, and 2) what can be done to move beyond the traditional lecture-homework-exam format used for most classes? I have been attempting to directly tackle the latter of these two this semester, which can potentially impact the first question so I address that one first and save the first fundamental question for a follow-up post.

Moving Beyond Lecture-Homework-Exam (LHE)

Before delving into my attempts at a different structure for my course, I need to give some background context for why I think we need to move beyond the traditional LHE format, particularly for design courses. One of my biggest issues with LHE is the lack of iteration. When you tasked with developing a design, from something simple to something significantly complex, you always go through several iterations. However, performing iterations in LHE is virtually impossible. It is difficult to cover enough ground in the lectures because there are so many different topics to cover. Even breaking up into small groups is virtually impossible simply because of the number of people in the course (~44) and the layout of the classroom (small auditorium). So there are limited ways to iterate in lectures. Homework and exams are hardly the bastions of iterations. Usually, they are testing a particular concept and/or equation usage. For homework, I guess you could partially grade the assignment and then give it back to the student to work on it some more. That would work but that misses the larger concept of multidisciplinary design, which is significantly larger than one homework.

Previously, I tried to circumvent this effect by limited the amount of homework I assigned and only really focused on the exams. For the exams, I chose to give take-home exams for a number of reasons. 1) No one does design in the timeframe that is typical for an exam. Exams are meant for testing concepts and/or equation usage but design requires a different (iterative) thought process. 2) There is simply too much information to parse to give an exam in the classroom. There are a number of different books that I use in class and recommend, I can only imagine simply the noise from paper shuffling would drive most people crazy. 3) Students could use whatever information they needed to get the problem done and I made sure that the exam problems were sufficiently difficult and involved such that they couldn’t be done in a few minutes.

This worked reasonable well for a few years. Students could work on multidisciplinary design and the problems were sufficiently involved for them to design some sub-components but it still lacked design iteration. Often, I would come across an exam that would have 96% of a problem correct but there inevitably would be some stupid, basic mistake in that 4%. And I do not mean a calculation mistake. Something like a screwed up order of operations or unit conversion in an equation (microradians is 10-6, big difference without that -6 in there…). As an instructor, what is one to do with this? The militant prof in my wants to come down with an axe yelling “why can’t you do the basics!?!?!!”. Whereas in reality, this is the type of mistake that would be caught during a design review (and hence iteration). So do I give no points or all points? Do I take off a lot or a little? There is a huge dilemma there. Also, it is difficult to judge between two different exams when both have dumb mistakes. Do I take off the same amount of points? Some might be a simpler mistake but leads to a bigger overall error. How should that be considered, if at all?

Another complaint about my take-home exam structure was from the students. Normally, I’m Teflon when it comes to those. We all had exam week when we went through school so quit complaining and get to work, etc. In the real world, deadlines overlap and converge all the time. My thought process with designing the exam was that it should basically make up for all the missed time doing homework throughout the semester. I was, in some cases, requiring 20-40 hours for those exams, which in aggregate is fine but the fact that it is lumped into one week is not actually fair. There, I am indeed overstepping some (unwritten) bounds about workload on the students.

(Potential) Solution to LHE

This semester, I decided to try something radically different. Instead of designing several HW assignments and a few massive take-home exams, I decided to have basically one completely open-ended system design for the students to tackle throughout the whole semester. I came into the first class with this design in mind, outlined it, and then wrote up a formal spec document (a few lectures later…) with explicit subsystems that I wanted to see designed/addressed. Essentially, I took the topics that I would normally teach and put on the exam and found a common theme that allowed them all to be considered in the design of this system. Now, the system I chose isn’t actually a real system because there are particular concepts that I want them to design which may not make sense with other unless they were forced together. Also, there is no scientific basis for the system for them to design; it is loosely real concepts but their explicit specs don’t make complete sense. However, from the perspective of “Einstein says he needs XYZ to prove general relativity, can you build it?”, I think that’s ok. It is good for Systems Engineers to fully understand the fundamental process their instrument implements, but that doesn’t make it mandatory. Rather, it is nice to know and understand but sometimes, especially on big projects, it isn’t 100% possible.

How did you implement iteration into this design project? It’s funny you should ask, Internet, because this too was a little bit tricky. Since this course doesn’t have prerequisites and most of the material they are asked to design with are topics that I cover during the semester, I had to think of something. What I came up with was to build a multi-part design problem where the first third of the project will be covered nominally between Sept 1 and Oct 1, the second third between Oct 1 and Nov 1, and the final third between Nov 1 and Dec 1. At the end of each “Part”, the students may turn in a design iteration. I say “may” because they don’t have to because it isn’t graded in any real sense of normal grading. But these design projects will be reviewed to see how well they can design that part of the system to the specifications outlined. My goal is to give students a bunch of comments back and a rough grade based on “how close are you to being done”.

When they move on to the next part, they also get a chance to refine the previous parts of the assignment. Thus, when they turn in Part 2, they are also turning in the second iteration of Part 1. Likewise, when they turn in Part 3, they will have a 3rd iteration of Part 1 and a 2nd iteration of Part 2.

What about the last part of the semester (Dec 1 – Dec 15)? The good thing about teaching an elective graduate course is that I do not have to be a gatekeeper. So that last part of the semester from when they do their 3rd iteration and turn in the final project is technically just filler lectures on different topics. I may fix mistakes in previous lectures brush up on a few topics that are needed for the project but most of the things that they need for the project will (hopefully) already be covered. So really, that time is just for me to give them broader concepts in instrument design and for them to really refine their projects for their final submission.

Well? How is it going so far? So far, I have somewhat mixed feelings about this structure. I think the concept has the right feel for what I am trying to achieve. I think the students are getting a more realistic picture of the whole design process and frankly, will be giving them more valuable insights than what can be taught and assessed via LHE. I should also note that the feedback I have received from students has been positive and when I have talked to industrial advisors, they like the practicalities of the course structure. However, right now, I’m not sure if I have the size/scope of the project correct. Given that this is a project that in totality is complete fiction but has sub-elements of non-fiction, I’m not sure if that is the correct way to go. Should the overall project be 100% practical? My fear with that is there is likely a design example to go by from an existing product/research paper. Conversely, there is no reason by the overall project must be totally applicable because if it gets the flavor correct for “iterative, advanced design” then the course has met its objectives.

There are also some other aspects that I am still iffy on. I did not do the best job planning out the semester in terms of lecture topics, my travel schedule, and effectively communicating this to the students. I think I uploaded the calendar to Blackboard on ~Oct 15, 6 weeks after the semester started. That is admittedly pretty poor. To do this correctly in the future, I would need to plan this out better right from the start. The other thing that I needed to plan out better was the actual project. I outlined the project on day 1 but did not have the full spec document until 2-3 weeks in. That too is pretty bad.

One aspect that I really like with the project, however, is that it really mimics how you would go about designing a system for someone doing cutting-edge research. The description of the project and bounds I put on the project were super loose. They have a similar feel of “well, we don’t know what exactly we need, but this should be close enough”. Because the “mythical process” described in the project is still relatively unknown, the specs are not fully defined. This means that I’ve given the students probably 70%-80% of the specs that they need for designing the system and they must devise the remainder based on their assumptions and design choices. This is fairly common, especially when designing systems for research purposes. For example, to get light into and out of the system, it is probably more practical to have a sample holder with a window. There is nothing that explicitly says they need to do this but if they make some basic design choices, they will inevitably come to the conclusion that they need a sample holder with a window.

The last thing that I’ll mention is that because there are loose constraints in some aspects, I’ve had to add specifications along the way. This is to either clarify something or prevent students from entering a black hole. To facilitate this, I’ve had to establish a FAQ, which is fine, except I am notoriously bad at updating Blackboard. So far, the one main takeaway from setting up a course in this fashion is that I need to do a better job of planning, upkeep, and management of course, particularly from the start. Hindsight always helps and beta testing of any product/process is never 100% successful the first time but I think for the future this is something I can work with.

I’ll report back at the end of the semester and let you know how it went.

Leave a Comment

Your email address will not be published.