🎨Course Final Project Guide
These are instructions for the course final project - other sections of Unit 5 represent optional modules that you can use or not use based on time.
NB: This final project guide borrows heavily from guidance developed by Jeff Olson and Manny Rodriguez at Giant Machines in our Interactive Web curriculum - this is both becuase we believe these to be best practices for projects generally, and to ensure alignment between courses.
Project Mode Guide
Project Mode Timing and Philosophy
Please note that this curriculum has a lot to cover - there is a strong chance that you either may not have time for a course final project, and that's okay. In that instance, we would encourage you to apply the concepts from this guide to the last project you encounter in the year (likely the Unit 4 final). We recommend at least a week of class time dedicated to the final, although 2-3 weeks could be doable depending on project scope and expectations.
If your students came in with more experience, there is a chance you have extra time at the end of the year. This project can take as much time as you would like, but you may also benefit from the extra, optional modules under 'Curriculum Extras.'
We believe project mode can be incredibly powerful, but only when it's treated with the care and attention it deserves. Please ground yourself in the following ideas:
The strongest student learning happens during project mode.
Lessons and labs are really strong ways to ensure that the introduction to a new topic or concept is introduced correctly, at the correct level of depth, and with opportunities to dig deeper, but even when led by the strongest teacher, the motivation for completing a lesson activity or lab will range across a class fo students anywhere from curiosity to compliance.
We know that motivation impacts learning, and project mode allows for student ownership in a way that a convergent assignment does not.
There is a profound difference between a teacher insisting that we should all type a line of code, and a student struggling to solve a problem in an effort to implement a feature that they came up with all on their own.
However, project mode isn't this powerful by default. It is essential that a teacher give students enough choice, agency, and planning time to get truly excited about what they plan to build - this may mean modifying or being flexible about the assigned prompt. Do not let students begin projects until every single group is at least somewhat excited about what they plan to build.
Projects are varied, and that's a good thing.
Students need to be allowed to work at a pace that keeps them squarely in their zone of proximal development for the duration of project mode. This necessarily means that your most advanced students will create a project that demonstrates far more mastery of a unit's content than your students who are still grappling with the essentials.
This is a feature, not a bug. In order to encourage students to focus on their actual project goals instead of shoehorning in specific features to best a rubric, your project requirements will have to be either flexible or minimal.
Student buy-in happens during project mode.
Creating student buy-in on their specific project paves the way for student buy-in to the entire content area.
A student without a strong interest in computer science may still take this class to get a specific credit, or to be with their best friend, or even without intending to, because it was the only class that fit in their schedule. Taught excellently, there will be moments of joy and discovery in the lessons and labs along the way, but those moments pale in comparison to a well-run project mode.
An excellent experience in project mode can be path-altering. It can reveal to a lukewarm student that computer science will open doors for them in any industry.
Team projects are more powerful than independent projects.
While some projects in this curriculum allow for students to express themselves in a highly personal way, we recommend finding opportunities - including in this final project - to work in groups of 2-4, rather than simply working alone. Group project mode outshines independent project mode, especially in these larger projects, for a number of reasons:
They present a much closer parallel to real-world programming work.
They leverage students' varied skillsets and reaffirm the idea that everyone has something to contribute.
They facilitate some low-stakes, organic peer tutoring.
They lower the project-to-teacher ratio, allowing a teacher to spend more time supporting each group.
They fold in additional real-world skills, like division of labor, team communication, prioritization, and compromise.
These are features of a well-run project mode, and require more support than a simple "work in groups" direction.
Planning and punting are the best ways to sustain student momentum.
One of the most common challenges in any sustained project work is the temptation for a student to say "I'm done" as soon as they've created anything at all.
This can indicate that a student really has a fully realized vision, but more often indicates that a student simply isn't that interested in what they're doing, and would like your permission to stop working on it.
This can be addressed in part with an explicit expectation that students "work the whole time," but that places the onus on a teacher to decide what additional features a group should add to their project, and thus the vision is no longer the student's, and the motivation has shifted back to compliance.
Have your students spend a significant amount of time planning (up to 1/3 of the total work time) to ensure that they are fully invested in the project, and have them generate artifacts along the way. Pointing back to now-soon-later charts, mockups, and feature roadmaps can ensure that students are always executing on their vision, and not simply complying with a directive to keep working.
Project Mode Best Practices
Ranked Choice Groupings
Student-assigned groups can leave some students feeling left out, and can let good friends who don't work productively together end up paired.
Teacher-assigned groups can overindex on the "icebreaker" mentality and result in complete opposites working politely together on a project that doesn't actually interest either of them.
The strongest grouping mechanic is any variation of ranked choice. Ask students to rank their top 6 project partners, or do ideation before project groups are formed and have them rank their top 6 project ideas. With those student responses in hand, you can create groupings of 2-4 that ensure that everyone is working with someone they've consented to work with, while still having enough control to ensure that unproductive pairings aren't repeated.
You can also do fold some social-emotional learning by asking more precise questions like "Who is someone who you don't know well, but think you could learn from?" and "Who do you most enjoy working with?" followed by "Who do you work productively with?" - especially if you specify that students must provide a different name in each field, these pointed questions can help attune students to the fact that group formation is about more than working with their best friend.
Difficulty Rankings
Students likely ideate their projects and features without a solid understanding of what exactly they're getting themselves into. Have students pitch their ideas, and then give them a difficulty ranking for the project they're about to undertake. This can go a long way to making sure students aren't walking into a project that will present a more significant challenge than they are prepared to or willing to face.
Here's an example ranking system:
🌶 - This project will require you to use a subset of the skills we've learned, and will not require you to stretch beyond that.
🌶🌶 - This project will require your group to learn at least one new thing independently.
🌶🌶🌶 - This project will require your group to learn multiple new things, and will be a challenge to complete within the existing time constraints.
🌶🌶🌶🌶 - This project will require entire new concepts that we haven't covered, and cannot likely be completed in the time we have. You will only be able to finish a more basic version of what you're envisioning. Your teacher may not be able to help if you get stuck, and you may have to compromise on the finished project.
🌶🌶🌶🌶🌶 - This project may not be possible with the tech that exists in the world currently. If you undertake this project, your teacher will not be able to support you along the way.
It's important to stress that a level 1 (🌶) project is a perfectly servicable goal - do not use it to communicate that a project is not ambitious enough. If a student has communicated a vision for something that is truly not ambitious enough for the current project (e.g. a Unit 2 project that does not use anything beyond Unit 3 content), this is an indication that the brainstorming launch could use fine-tuning, either in the examples shared, or in the way the project criteria is shared.
It's also important to be clear that you're actively discouraging that students tackle a level 4 or 5 project.
Feature Roadmap
As students begin brainstorming their projects, encourage them to break their project up into versions, and help them define the most basic version (the Minimum Viable Project or MVP) of their idea before they begin building anything.
Here are some examples of how to scale down student ideas to more manageable prototypes:
When a student wants to build a college matching site, encourage them to start with only three possible matches (instead of hundreds).
When a student wants to create a lifestyle improvement app that addresses nutrition, exercise, mental wellness, and boundary setting, encourage them to identify which of these features is most core and build it out first.
When a student wants to help a user pinpoint their nearest grocery store, start with the simplest location input (e.g. a zip code) and a hardcoded list of 5 grocery stores.
Now-Soon-Later Charts
This strategy can be helpful for keeping students on their feature roadmap. Ask students to take a piece of paper and fold it into thirds (alternately, you can provide a pre-made template) and label each third as 'NOW', 'SOON', and 'LATER.'
Students will brainstorm the things that they must do to create their project, write them down on post-its, and bucket them into the three categories. NOW represents the earliest things they must do to get ready. SOON is next steps, and LATER represents stretch goals. It's important that students are specific in their steps and that they split the steps up so they are achievable - for example, writing 'Code a button to change color of background' is better than 'Code all buttons for project.'
If you have space, considering having a spot in the room where students can place their post-its once they've achieved a task. As the 'NOW' section empties out, they will move post-its from the SOON column into the NOW, and items from LATER into SOON.
Mockups, Design Guides, & Wireframes
Students have spent the year working on a very visual project. It's likely that their final project will include many visual components. Before they dive into coding, ask students to draw a mock-up of the design so they have something to reference - especially when completing the project as a group. Students may consider making a few mockups and deciding together on the best version.
Mockups will also ensure that the teacher can help students with a specific element of the page with a holistic view for how it will be incorporated into the project as a whole. This lessens the likelihood that a teacher will advise students to do something one way in the early stages of a project and then advise students to completely redo that section of the page when it's placed in the larger context of the project.
Design guides can also help ensure that students are agreed on the creative choices and boundaries that will guide their front-end work. Design guides in this course might include a list of colors, preferences for naming conventions of variables/functions/classes/objects etc, or even a mood board of images.
Standups
Time permitting, launch each class with a brief full-class share out of what each group is working on, and invite them to give a general sense of their team's readiness to start work. If you have short periods and your class is large, working independently, or in small and numerous groups, consider assigning teams to certain days for timing purposes. Teams can still display a color without a verbal share in this instance to give you feedback.
A team is 🟢 green if they are ready to start work immediately.
A team is 🟡 yellow if they would appreciate your input or feedback.
A team is 🟠 orange if they have a feature that is blocked, but can work on something else while they wait for you.
A team is 🔴 red if they are totally blocked, and cannot continue work without help.
This standup will present you with an opportunity to both triage your support, and connect teams that are struggling to work on a feature with teams that have already built a similar feature. That will help the struggling team get unstuck sooner, and will also offer the successful team a chance to engage in an in-depth reflection on the topic. Most importantly, this affirms the real-world truth that as a software engineer becomes more knowledgeable and more senior, more and more of their job is about passing along their knowledge to others.
1:1s
Project mode affords an opportunity to check in with students individually while their peers continue productive work.
One-on-one conversation with students can help a teacher pinpoint when a student group needs help resolving interpersonal tensions, or spot an unequal division of labor and resolve it before the project ends.
Ask any questions you like during a 1:1. Consider including the following:
In your opinion, how is the project going so far?
What are you working on?
Is your group being helpful?
How do you feel about this class so far?
Midpoint Presentations
If you are entering this project with the expectation of several weeks of work time, midpoint presentations can be highly valuable. When some groups lose a little momentum, midpoint presentations can facilitate some cross-pollination of ideas.
Have each group share out their unfinished projects and solicit feedback (one glow and one grow) from the other groups.
Midpoint presentations can help turn the imposter syndrome someone might feel seeing another group's excellent work into an entry point for collaboration and support. If a group of students keep talking about another group's excellent design work, they still have time to ask that group for help with their design before their project is due. You can add in more specific guidance to facilitate these connections if necessary.
Final Share-outs
Make sure that teams have some opportunity to share out their final projects with their peers, and possibly even a wider audience. These could be formal presentations, informal presentations, or even just a link sharing activity.
Whatever you do, just make sure that student work is seen by a larger audience than just the person grading their assignments. This is a great time to invite other teachers from the school - or even parents! - to join and get a sense of what has been going on in your class.
Flexible Grading
The strongest project modes occur when you can take students' minds off of grading altogether.
While students should have a sense of what the expectations of project mode ought to be, using grades as the primary motivator for student work will lead to situations where students who are struggling to meet a specific standard feel tremendous stress, and students who meet the standard easily will have a defensible reason to say "we're done" and stop work.
Emphasize the core skills students need to meet in the planning phases, and de-ephasize it during the work phases.
Consider de-emphasizing demonstration of specific content knowledge, and emphasizing the following items in your rubric.
Worked the whole time.
Equitably divided the labor.
Completed all planning documents, including mockups, design specs, MVP definition, and feature roadmap.
Presented their work & completed corresponding presentation practice or planning.
Learned at least one new thing, or demonstrated a skill from a lesson / lab that they struggled with earlier.
A student or student group that does all these things should receive a top grade on any given project.
If a teacher is using a mastery-based grading system, they should alert students to opportunities they have to demonstrate mastery of a skill they struggled with previously.
A good grading system should encourage student risk-taking and the decision to work outside your comfort zone, not reward it.
If your time permits it: consider having students grade themselves, either in a 1:1 conference with you, or as something they fill out at the end of project mode. Students will be shockingly honest when asked to justify their grade, and it's a good habit to encourage them to argue - by providing evidence - for the grade they think they deserve.
Project Mode Modifications
A teacher is free to change the topic of any of the projects described in the unit guides. Be cognizant of doing so in a way that will allow all students to find something that excites them while still showcasing the skills the project is asking students to demonstrate.
Be cautious about overfitting to one type of project. Turning every single project into an e-commerce simulation will get old for some students quickly. Likewise, turning every project into a research assignment about famous computer scientists will demotivate students who motivated by interactivity and design.
We advise re-starting project mode from scratch for each new project. That is a strong recommendation, as it allows for students to learn from past mistakes and start fresh, working with new partners, and without dealing with legacy code or code debt incurred in the last project mode.
However, if a teacher is prepared to deal with those challenges, this course can also be run where project groups are locked from unit 1, iterating on a single idea at each new project sprint, adding new functionality and features each time students learn something new.
Teachers of this course are also welcome to explore the middle ground, where students are allowed to decide whether they want to start from scratch or iterate.
Final Project Prompts
For final projects, students should be encouraged to use at least one concept from each unit taught so far. The prompts given are intentionally open-ended and students are encouraged to bring their own ideas to the table.
Final Project Prompt
Present students with one of the following final project prompts. They will create an interactive program that:
Makes people feel __________. (Insert your own emotion when giving the prompt - happy, joyful, a burst of serotonin, etc.)
You *can* have students pick their own emotion, but be aware of the work they might do to create negative emotional projects.
Assign everyone a random phrase or random sentence. They must create an interactive project that embodies the phrase/sentence.
The best part is asking them to explain/justify these projects.
Teaches someone something.
Beyond the prompt, the actual projects themselves can take any form, including as games.
Final Project Requirements
Again, these are fairly loose and open ended. The following are requirements that you may want to give students, but that you can vary or make more specific as you see fit:
Showcase a skill from each unit - you could request specific skills, like 'must write at least one function,' or 'must create at least one class,' etc.
Include clear code comments - you can ask team members to label the project parts they were responsible for, as well.
Create a written statement explaining/defending your work. Get creative with this one!
Last updated