Project Mechanics

Forming Teams

The project is to be done in teams of four to five. The assignments will be the same for either size team. Groups of five will have less coding to do per person but will also have to manage the interactions between more people. We will not allow teams of less than four. Your first assignment is to form a project team; you should do so as soon as possible. If for any reason you need to switch groups, you need to get explicit permission of both the TA of your previous group and the TA of your new group. In general, switching teams will only be approved effective after the current assignment is completed.

Group Evaluations

In order to encourage every member of the team to contribute equally, you will submit a group evaluation form after each phase of the project. Each of you is required to individually submit a form with a quantitative assessment of the relative contributions of each of your teammates, excluding yourself. If you have N people in your group, you have (N- 1) * 20 points to allocate among your teammates, proportional to how much they contributed to just this assignment.

It is our expectation that for most groups, all of your teammates will pull their weight, and so you will be able to simply give 20 points to each member. But if you have as teammates, Sam Slacker, Annie Average, Hugh Helpful, and Connie Conscientious, for example, then you might allocate your 80 points as follows:
Annie Average 20
Sam Slacker 10
Hugh Helpful 25
Connie Conscientious 25

If on the next assignment Sam starts pulling his weight, you should reflect his new performance (and not his past record) in the assessment for that assignment. We will use this information in determining final grades. By the way, many engineering companies use peer review to determine annual raises, and so making your peers think you are useful is a good skill to have.

Late Policy

Because design reviews must begin shortly after you turn in your design documents, design documents must be turned in on time or there will be a severe late penalty. Design documents are always due at 11:59PM.

We will use flexible slip dates for the implementation assignments, which are also always due at 11:59PM. Each team is given an automatic extension of 5 calendar days. You can use the extension on any assignment during the semester (in increments that are rounded up to the nearest integer). For instance, you can hand in one assignment 5 days late, or each of five assignments 1 day late. For project assignments, the slip time will be deducted from each team member's dates. This should let you schedule due dates around the due dates for other courses. No assignment will be accepted more than 5 days late.

After you have used up your slip time, any assignment handed in late will be marked off 10% per day. Extensions will not be granted.

Grading Policy

The grading for the project phases will be as follows:  We have structured the grading in this way to encourage you to think through your solution before you start coding. If all you do is to work out a detailed design for what you would do to address the assignment (and if the design would work!), but you write no code, you will still get almost half credit. The autograder test cases will consider whether you implemented your design correctly and efficiently. For the style component, your TA will look through your code, making sure you followed the rules, wrote clean code, and commented it well. Part of being a good engineer is coming up with simple designs and easy to understand code; a solution which works isn't necessarily the best that you can do. Thus, the design and code style grades will be based on whether your solution is elegant, simple, and easy to understand.

After you turn in the design document, your TA will conduct mandatory graded design reviews with each group, where you will be asked to explain and defend the design you are using for implementing each assignment. All project members must attend the meeting or your project grade will be penalized.

The intent of the grading for the project is not to differentiate among those students who do a careful design and implementation of the assignments. In other words, don't implement some complex feature just because someone else in the class is implementing it. Our expectation is that most of you will get close to full credit on each assignment. Rather, the grading is to help identify those students who (i) don't do the assignments or (ii) don't think carefully about the design, and therefore end up with a messy and over-complicated solution. You cannot pass this course without at least making a serious attempt at each of the assignments. Further, the grading is skewed so that you will get substantial credit, even if your implementation doesn't completely work, provided your design is logical and easy to understand. So don't pull an all-nighter just to fix the last remaining bug in your solution.