You Should Give Open-Ended Projects to Your Students

For my friends in the humanities, it probably comes as a surprise, but our STEM programs are really allergic to open-ended projects. As a result, I figured I would pitch them today. The Current State of Education Education is fundamentally built on behaviorism (yes, I am ranting about behaviorism again). As educators, we perpetuate the ideas of behaviorism by assessing students and awarding (or punishing) them with grades. In essence, students are conditioned to value grades and adopt certain behaviors like studying to improve their chances of earning good grades. While that sounds like a decent system (and in some ways, it's been an effective way to teach for some time now), it doesn't ever get to the underlying issue of learning. We assume because students get good grades that they must be smart, but there are actually a variety of behaviors that can lead to good grades without learning. For example, cheating is a great way to get good grades without ever engaging in the learning process, and cheating has certainly gotten easier over the years with access to the internet and tools like ChatGPT. With the rise of cheating, educational institutions tend to opt for the silver bullet: high-stakes testing. The idea being that a standardized examination can be provided in a proctored setting where cheating is prohibited. Further, by limiting the amount of points students can earn through other assessments, it is much harder for a cheater to squeak through. Of course, aside from preventing cheating, high-stakes testing has almost no further benefits. Instead, it has loads of side effects. For example, an exam could catch a good student on an otherwise bad day, resulting in an inaccurate assessment of a student's abilities. Likewise, the stress induced by high-stakes testing has many known mental health effects. On top of that, I would even argue that most exams don't even test for what they set out to test. In my entire undergraduate degree, I was under the impression that learning the concepts was more important than memorizing problem solving algorithms. Yet, the latter is what's rewarded. You can really get through all of your calculus and physics classes by memorizing problem solving algorithms. To make matters worse, even if we toss testing to the side, assignments are often not that great for learning either. Generally, at least in STEM classes, you'll find that assignments are close-ended. In other words, every problem has a known answer. This is convenient from a grading perspective because the student is either right or wrong. However, it does not map to reality. Often, there are multiple solutions to a problem, and the important bit is if the student can justify their solution. I frankly do not care if a student memorized some definitions or algorithms. I want to know if they can make informed decisions and justify those decisions. Barriers to Creating an Open-Ended Project Ultimately, the question becomes "how do we shift education away from the behaviorist model?" While there are many, many answers to this question, I wanted to focus on one small change you could make to one of your classes: include an open-ended project. Open-ended projects differ from the more traditional problem sets you might see in a STEM course in that they do not have a "solution." Instead, you pose a problem and some constraints, and you ask the student to propose a solution. Now, there are plenty of barriers to creating an open-ended project, but I believe any qualms you might have can be addressed. For example, I don't think there is much debate in the idea that open-ended projects are harder to grade. You have to look at each solution with an open mind, which is time consuming. However, you can offset the challenge of grading by including peer review (and even peer grading), so you can focus on assessment while the students still get feedback. The other concern I often hear is that students are not equipped to complete an open-ended project. I think this argument is getting at the idea that students can solve isolated problems, but they struggle to integrate their knowledge when needed. Of course, I would counter this by arguing that you can include scaffolding in the open-ended project, so students aren't left to complete the entire project from scratch. Scaffolding also solves the problem of making sure all learning objectives are covered in the project. I'll show you how I do this down below. Likewise, I sometimes hear that some students don't want autonomy. Therefore, an open-ended project is going to be tough for them. While my gut says "tough luck," I also understand this perspective. There are certainly times where I've thought "just tell me what to do." As a result, I think it's reasonable to accommodate these students by providing some possible starting points. I'll also share how I do that below. However, before I share details of the project I created, I want to take a moment to list off some additional benefits of assigning an open-ended project. The Case for Open-Ended Projects Despite how scary they might be to implement in a classroom, I find that open-ended projects have a wealth of positives. You might be surprised by some of them, but many of these are rooted in the very real experiences of both students and educators. The benefit that prompted the writing of this article was recommendation letters. I write quite a few recommendation letters a year. Currently, we're a little over halfway through the academic year, and I've written 18 of them for students applying to grad schools, research programs, scholarships, and internships. Naturally, you're probably wondering how I even know 18 students well enough to write them letters, and you'd be write to criticize me for it. However, I would argue that the open-ended project I give students has made it so much easier to write letters. Now, when I sit down to write a letter, I look back at the student's final submission, which includes things like software, testing, and documentation. In addition, I also have students reflect on the process, so there are even excerpts I can read through to refresh my memory of the student. Another huge benefit is being able to reignite a student's passion for the subject. Often, when we give close-ended assignments, we strip students of their creativity. When we give open-ended projects, we're able to still constrain the students while allowing them to flex their creativity. As a result, students will have more buy-in since they're creating original work. Certainly, close-ended assignments have their place. For instance, they can expose students to certain ways of problem solving. However, never allowing them to complete something from scratch will do them a major disservice, and it might even lull them into a false sense of security in a real world context. Speaking of the real world, perhaps the most obvious benefit is that open-ended projects more closely map to the real world. In general, students will learn all the necessary skills to work an industry job, but there is still a lot they will have to learn on the job. All too often I hear "I learned more in my first week on the job than in all my years of college." While I think there is some truth to that statement, I also think college teaches you how to learn quickly, so of course you pick up training on the job quickly. That said, we could still do more to map our curriculum to the real world, and I think open-ended projects are an opportunity to do that. An Example Open-Ended Project It's likely that I've written about this project somewhere else on this site, but I tend to lose track of what I've written over the years. Regardless, I'll share how I run what I call my "portfolio project" in my software design courses. For context, we teach a rigid software discipline that is steeped in abstraction and inheritance. While I don't fully agree with its principles, I feel like we do our students a disservice when we don't give them a chance to embrace the discipline through an open-ended project. As a result, I came up with what I have been calling the "portfolio project." In this project, I ask my students to design a software component that fits within our discipline—that's the only constraint. In other words, I let them develop whatever they want as long as they can get it to fit in our box. To ease them into this process, I scaffold the development into six parts: Part 1: Brainstorming In this portion of the assignment, students are asked to reflect on their passions and career goals. Then, I ask them to brainstorm up three different components based on their reflection. For these components to fit the discipline, they have to be able to divide up their design into two sets of methods: kernel methods and enhanced methods. As their names suggest, the kernel methods are the most basic methods needed to get their component working. Then, the enhanced methods are built on top of them. Part 2: Proof of Concept When brainstorming, students come up with a range of ideas. Some are much too large in scope and others might be too small. As a result, I ask students to prototype their design without following any of our discipline. In other words, I let them develop their component however they like, so they can prove to me that their design is feasible. Part 3: Interfaces As a part of our discipline, students are asked to develop two interfaces: one for the kernel methods and one for the enhanced methods. Because these methods are included in interfaces, they cannot contain code. Instead, the purpose of this step is to develop documentation (specifically, in the form of design by contract). Part 4: Abstract Class One of the core principles of our discipline is being able to create multiple versions of the same component with different implementation details. To make this possible, we use an abstract class layer where we implement all of the enhanced methods using the kernel methods. This gives students a chance to see the inner workings of an abstract class. Part 5: Kernel Implementation If you're following the design up to this point, all that is left for students is to create a class that inherits all of the pieces above. All that is left is to implement the kernel methods, which requires making decisions about implementation details. We take it a step further by defining a "convention" for our underlying data structure as well as a "correspondence." All of these are things that the students would be deeply comfortable with by this point. Part 6: Finishing Touches At this stage, I ask students to reflect on their project, add testing, and give me two sample programs showing the implementation details. The entire project is 100 points, where the first five parts are "formative" and 10 points a piece. Meanwhile, the last part is summative and 50 points. I take their total score and replace the lower of their two midterms with it. In terms of some of the unanswered questions from above, here are my thoughts. First, if you're wondering how I assist students who want to be told what to do, I just share with them previous student ideas. At least that way, they can pick a few ideas from a list instead of coming up with their own. Second, if you're wondering about peer review, I have peer review built into my learning management system (Canvas). I can assign three students to each submission. It doesn't count as a grade, but I figure it's mutually beneficial to the students. On one hand, students get extra feedback. On the other hand, students can see other examples of designs. Since it's unlikely that any two students will be developing the same thing, there's really no risk of cheating. As an added bonus, I ask students to complete the project entirely through GitHub, where they will submit to me pull requests. In fact, the project is built off a template repo. Naturally, the punchline is I actually let students share their components on GitHub, which is not the norm for most computer science courses (academic integrity and whatnot). If you want to see some samples, I started building out a small repo of links to student work. They have to submit pull requests to me, which is why the list is so thin. That said, I am slowly accumulating submissions. Otherwise, that's all I think I want to cover today! If you liked this piece, there's plenty more teaching advice I've shared below: How I Automated My Grading Responsibilities So You Want to Be a University Educator 6 Tips for New College and University Educators Likewise, I'd love it if you hopped over to my list of ways to grow the site. At the very least, you'll find the link to our Discord, where you can chat with me directly. Finally, I know I sometimes share additional resources on my Python articles, so I think I'll try that on my education articles. Here are some education-related books that might provide you some value (#ad): Otherwise, thanks again for reading!