Collaboration Policy
Fill out and sign the last sheet. Turn it in at your first lab.
Since CS15 does not have any examinations, your grade is based solely on your homeworks and programs. Therefore, in order to evaluate you in the course, we must be sure that your assignments are your own work.
In the past, CS15 (along with other CS classes) has handled this issue by implementing a very strict non-collaboration policy, in which students could not work together at all. This was the policy for over 20 years.
Several years ago, we changed the policy to be more liberal. We feel that the benefits of allowing students to discuss the course material and assignments outweigh the possible problems of people taking the wrong kind of advantage of the collaboration policy. Since then, students felt that they learned a great deal from each other and enjoyed having an opportunity to learn in an informal setting.
The basic premise of the policy is in line with Brown's general policy regarding written work as described in the Academic Code of Conduct and Tenets of Community Behavior. You should do your own thinking, your own design, your own coding, and your own debugging. You should never let yourself be led by another student or receive an amount of help which makes an assignment significantly easier. Conversely, you should never assist another student in a matter that would overly lead them or make their job much easier.
This is important to keep in mind: Just "helping a friend out" is okay only if the help does not breach the collaboration contract. Otherwise, it is as much a violation as receiving that help. This goes for everything: debugging someone else's code, giving someone your design, letting someone copy your code, etc. ...
We strictly enforce this policy. Cheating has been a significant problem for the CS department in the past, but because of TA alertness and a software package called Measures Of Software Similarity (MOSS), illegal collaboration is easily detected in CS15.
The main purpose of the policy is to allow students to discuss the high-level design of their programs. As you will learn, design is the process of determining how to break down your program into objects, what the capabilities and properties of the objects will be, and how they interact. Discussing your design will allow you to find problems with your program before you start coding and to think about different ways of approaching a problem.
Levels of Collaboration
1. The following actions are encouraged and are not considered collaboration
- Discussing material covered in lecture or the textbook, or any concept of object-oriented programming.
- Discussing cs015, swing, or other support code, as long as it is a technical question, and not "Where do I put this class in this assignment?"
- Discussing the requirements of an assignment.
- Asking questions about syntax. For example: "How do I declare an instance variable?"
- Discussing general techniques of designing, coding, or debugging. Saying things like "I looked at the nouns to determine what classes to use" or "When my program crashes, I first look at the line where it says it crashed," is fine. Saying things like, "To fix my bug, I changed the first line of my react() method to make it initialize the variable," is not fine.
2. The following is considered acceptable collaboration. If you do this with another student, we require that you include his/her name in the header comment of your App class. You'll find out what the App is later. This is akin to acknowledging a reference in a research paper.
- Discussing the design of an assignment. Design is a crucial part of the programming process, and discussing it is very valuable. However, learni ng to work through design problems on your own is a skill that requires time and practice. Try to work out as much as you can on your own, but discussion amongst students is fine, as long as it is documented.
- There is a limit to how you can discuss design, however. You may not take away any written or recorded notes from these discussions. You must erase the whiteboard, throw out notes, etc. before you start coding. A program written down is considered too close to creating a "blueprint" for solving the problem, and we will be forced to examine further.
- Your discussion should focus on conceptual aspects of the design without getting into specifics. If you find yourself discussing class names and method names, you're going too far.
- There is no penalty for permissible collaboration with another student, as long as you document the students with whom you collaborate.
3. The following things are not allowed in the policy:
- Copying code. This is the most blatant violation. You should not be writing down anyone else's code, or allowing anyone else to write down your code, let alone taking someone's code and modifying it to make it look different -- all of these constitute plagiarism. Remember, we have software designed explicitly to look for undue similarity of code.
- Discussing pseudocode. Pseudocode in CS15 is close to discussing the code itself. If you've gotten beyond discussing the basic kinds of classes and initial relationships, you're ready to work on your own.
- Taking someone else's design. Discussing basic design with someone else is okay. However, just taking someone else's design without trying to design a program yourself is not allowed. It is akin to taking someone else's outline for a research paper and basing your paper on that.
- Debugging with another person. Sitting at the same computer with someone else and trying to fix a bug is not allowed. It makes it too easy to look over someone else's code and allows (sometimes unintended) code-copying. Describing your problem to someone and asking for advice on how to fix it is okay, but you should debug it by yourself.
- Looking at someone else's code. You should never read anyone else's code, whether it is on the screen or written out by hand.
- Working on homeworks together. Homeworks should be done individually.
- Asking for help on something you haven't thought about yourself. Always make every attempt to tackle a problem yourself before asking another student or a TA. It will help you become a better programmer, as well as a better student.
- Being careless about files in your directory. Being careless and allowing other students to see the files in your directory is not appropriate. If you do not intentionally change file permissions, this will not be a problem.
We believe that this policy is explicit enough to guide your judgment and that we have not left you much gray area. If you are ever in doubt about the legality of an action, don't do it, or at least be sure to clear it with a TA. When we confront a student with a case of suspected violation, an answer of "I didn't know that this is wrong" will not find sympathy.
You are always expected to initially approach a problem on your own and seriously attempt to find a solution. You are honor-bound to preserve your independence of thinking. And remember that TAs are the only people who can give you definitive answers to your questions. Students come into CS15 with varying levels of knowledge. Only the TAs have been through the course before and have been trained during a weeklong "TA Camp" to know how the assignments and support code work.
We are doing this to make learning easier and more effective for all students. Please help us make this work. If you think there is a chance a discussion may infringe upon this contract, play it safe and ask a TA. That is what the TAs are there for.
Note that we strictly enforce this "all written work must be yours" policy by taking suspected cases to the Deans. Almost always, the result is a directed NC on your transcript and parental notification.