Partnership Structure

For project 2, we require that every student work as part of a design group, unless you have a special reason that prevents you from doing so. See the end of this document for an appeal form.

In project 2, you'll form a 2 to 4 person design group. For the first week of the project, this entire group will collaborate on an initial design, which will be reviewed during lab 6.

Afer design review, the design group will split into two independent coding teams (ICTs) of at most 2 people each. These ICTs will work mostly independent of the other ICT from the original design group, see below for details.

For example, suppose Ali, Baraz, Crispian, and Dana form a design group. During week 1 of the project, all four will work together to come up with a design, and then after the design review, Ali and Baraz will pair off to form an ICT and complete one implementation, and Crispian and Dana will pair up to form the other ICT and complete a separate implementation.

For 3 person groups, the implementation teams must have no more than 2 people, that means one ICT will have two people, and the other will have one. We strongly encourage programmers who rate themselves as a 3/5 or less in programming skill to be part of a 2 person ICT. If you feel like you're a 4/5 or 5/5, do what feels right.

Why Partnerships on Project 2?

For the last couple of years, the Spring 61B design project has been a solo project. We found that this caused far too much stress, particularly for students new to programming. We're hoping that by formalizing the design process that we can make things better.

There's also the fact that when you go to job interviews, it is very likely that you'll be asked to describe a time you worked with a team under some sort of duress. This project will likely provide such an opportunity.

Rules for ICTs

For this project, you're welcome to divide and conquer. We encourage you to explore the idea of pair-programming, but it is not required. It is also not required that you work in the same room, though it is highly encouraged because this is more fun.

Important note: Design teams should not implement as one giant group! Each ICT should work independently. Do not share implementation code with the other ICT with whom you share a design.

Rules for Design Groups

The two ICTs comprising a design group can keep talking after design review, but they should not work closely. However, it is permissible to share the join method and basic table code that you created while prototyping your designs.

We expect that by the time the project ends that the two projects will have diverged to some degree, i.e. you'll end up with somewhat different classes and methods. You should not share detailed lists of your methods with the other ICT. We don't want one team to do the design, and the other to basically do a "fill-in-the-functions" style project, which takes away part of the experience.

You should not share test code (though we're thinking about revising this). Copying code from the other ICT will be treated as plagiarism.