The project is an open-ended, agile software development experience. Think of it as an activity that takes place instead of a second prelim—and that requires corresponding intensity.

There will be three milestones in the project: Charter, Beta, and Release. In the Charter phase you will form a team and propose the system you plan to build. In the remaining phases you will build out and demo to your discussion section some part of your system, write a brief report on your progress toward your final goal, and submit your code for evaluation.

Table of Contents:


Milestone Due Files
MS0 Handout
MS1 Handout
MS2 Handout

Project Requirements

The primary educational objective of this project is for you to build a system from scratch in OCaml with a team.

Size: You should aim for a system that has a few hundred lines of OCaml code per team member. That’s not a hard requirement, just an estimate. See the MS2 handout for more details.

Source control: You are required to use Git to manage your source code. Unlike other assignments in this course, you are welcome to make your work on this project public.

Library warning: Neither graphical user interfaces nor networking are required. Be warned that both can be difficult, and no one on the course staff will be able to give you much help with them. So if you want to go for such a project, have a backup plan in case it becomes too hard to get done in time.

Project Ideas

Pick something that you are excited about! Here are some ideas to inspire you. Note, however, that in Spring 2020 we are working virtually and the semester has been shortened by a week. It makes sense to be modest with your goals and we have adjusted expectations about scope appropriately.

And here are some harder ideas:


Teams are the norm in industry, building bigger and better software than one person could do alone. Teamwork is a skill that you can develop, just like programming. Now is a good time to develop it. We hope this project gives you an opportunity to do so.

Team formation: You are allowed to form your own team. The section TAs willl be happy to help match you with others if you are having trouble finding partners. The MS0 (Charter) assignment has more details about how that will work. The choice of who is on your team is mainly up to you, but the professor does reserve the right to insert and remove people from teams to solve personnel problems (e.g., somebody drops the course, irreconcilable creative differences, etc.).

Team size: Your team must have two or three members.

Personnel changes: After the project begins, any changes in team membership must be approved by the professor or one of your section TAs.

Peer ratings: Your team will be asked to establish expectations in writing, and to conduct peer ratings of teamwork—not of technical ability. The peer ratings your team members submit of you will become part of your grade on the project. Specifically, 80% of the project grade will be for the system you build as a team, and all of you will share the same grade for that. But 20% of the project grade will be individual (i.e., could differ for each team member) and determined by those peer ratings.

Managing Conflict

Conflicts may arise in solving assignments together. Part of teamwork is managing conflict. We expect you to handle it professionally. The course staff will be available to help you with that. In the worst case, it will be possible for the professor to remove a team member, but not before a serious attempt is made to address the issues at hand by both sides.

How to handle non-cooperative team members:

A student who is consistently doing all the work for their team without any help from their teammates may follow the same process to quit from their team.

Removal and quitting may result in grade penalties, if they result from failure to be good team citizens. The amount of the penalty will be determined by the professor based on the details of the situation.


The project is organized as a sequence of 2-week phases or sprints, during each of which you build some “shippable” increment of your system. That means implementing some functionality that can be demoed to your section and TAs. It’s your choice what that functionality is.

In a successful sprint, the functionality you implement will offer clear value to users of the system—value that can be seen through a running demo of the system, rather than code that isn’t yet runnable or integrated into the system, or whose value can be seen only through unit tests.

Using A2+A3 as an example, a successful sprint would involve building out some new player commands and being able to demo that they work in the interface. An unsuccessful sprint might involve adding JSON fields to the adventure file and adding parsing code for them, but not being able to see the effect of that as a player.


Of the total percentage dedicated in the syllabus to the final project, we expect the breakdown to be as follows:

Why is MS2 worth so much more than MS1? It’s not because you should do five times the work all at the end: it’s because we don’t want any initial stumbles to have too great of an impact. We encourage you to work at a consistent pace throughout the project.

The TAs for each section will, at the end of the project, be able to nominate about 20% of the projects in their section for a bonus of 5%. So, the top 1 to 3 projects in a section could receive a bonus. We hope that this results in a small and healthy amount of friendly competition. But, no one should get overly excited about the effect on your final grade.