Team Project's Individual Responsibilities

Projects in this course are intended to be large and challenging, so they require steady, consistent, work by everyone in the team. Only if you put in the time each week will you see measurable progress and not have to pull "heroic" all-nighters near the end. Unfortunately, conflicts are likely to occur so please let the Teaching Team know as soon as possible — even if it has happened just once or twice since it is better to deal with the situation early rather than having a big disaster at the end when little can be done to get back on track.

Meetings

You are expected to participate in all team meetings because when meetings stop getting full attendance it is a clear sign that a project is not going to be successful.

The following expectations give everyone a fair chance to participate in the project:

• let people know in advance if you will be late or unable to attend a meeting or online discussion
• work out an appropriate way to make up for your absence (e.g., meet at some other time)
• listen to everyone (rather than doing your own work) and contribute where appropriate
• allow everyone to contribute to every design idea or proposal
• each meeting should end with clear action items for each member of the team
• likewise, for online discussion forums, there should be an easy to access list of everyone's current action items

Functionality

You are expected to develop code that implements new features or significantly improves the project's design every week (regardless of whether there is an expected class deadline or not) because the project only truly moves forward when individuals (or pair programmers) sit down and get work done.

The following does not count as successful work:

• code that is not functional (e.g., code that does not compile or that has such severe bugs it effectively does not do anything)
• code that works on your local system, but is incompatible with the current version of the repository code
• code that is submitted too close to the deadline for your team mates to properly integrate with the existing repository code
• code that is emailed to someone else on the team or otherwise having them submit it into source control because GIT is not working properly for you (remember, pair programming should be documented in your commit message)

It can be a little difficult to exactly quantify what a reasonable amount of code is: sometimes, just the right 150 lines might be really hard to write; other times you can add 1,000 lines of duplicated boilerplate and still have accomplished nothing. A good rule of thumb is to work with your team to agree on what needs to get done each week and then get a least a basic version of most of that done.

Clean Code

You are expected to develop code that is easily readable, free of duplication, and meets the course Design Checklist as appropriate for the current project because that does not additionally burden your team mates and shows you are learning course concepts by practicing them in your code.

The following does not count as clean code:

• code that does not follow the team's naming and formatting conventions
• code that does not follow the team's current API
• code that is a mess, making it "unreadable"
• no code definitely does not count!

Interesting Design Challenge

You are expected to take responsibility to solve at least one "interesting" design problem because many design problems exist in any project of significant size and it is valuable to your personal growth to take at least one opportunity to show your design skills individually instead of just implementing code based on other's directions.

Your resulting design should:

• involve multiple interacting classes
• use a design pattern or other "advanced" technique
• showcase skills you have learned in this course beyond the Design Checklist

Although you are encouraged to discuss your design with your mentor TA and team mates, the final decisions should be yours and you should be able to justify them. You will be responsible for discussing this problem and your solution in your analysis, as well as implementing the design in code backed by your GIT commits. The quality of your individual design will form a large part of your overall project grade.

Going Above and Beyond

You are expected to go above and beyond to help another team mate at least once during the project because you are all in this together and that is a significant way you show you are being a good team mate.

For example, the following might be needed to make a project a success:

• helping someone solve a particularly nasty bug
• helping someone understand a technical concept or the important concepts of a design change
• doing another person's part because they are suddenly ill
• NOTE, refactoring someone else's code without their permission is never needed or positive for the team

This does not have any direct mechanical affect on your grade but will be evaluated on a case by case basis when determining your final project grade, so please help give credit to others when it is due by letting us know specifically how they helped you.

Resources

• Introduction to Teamwork Is An Individual Skill by Christopher Avery, Meri Walker, and Erin O'Toole Murphy
• Group Project Survival Guide from Babson College