Here is more concrete information on the collaboration policy, with specific examples. Please don't hesitate to ask if you find anything unclear.
"Your code is like your boyfriend or girlfriend. It's okay to talk about it on an abstract, high level. But you don't want to go into the specific details, and you certainly don't want to share."
- Pascal Van Hentenryck, Professor of CS, Brown University, 1997
Much of your course grade (and effectively all of your learning) comes from doing the assignments. I can talk about code for hours in lecture, but you will only truly master the material after writing code. The programming assignments can be challenging, illuminating, time-consuming, rewarding, and frustrating (all at the the same time!) but hopefully you will end up proud of your accomplishments and the new skills that you will gain.
It is important that you (or your team) do your own independent work on the assignments. However, that doesn't mean that you can't ask questions or get help when you get stuck. There are ways to get help that are acceptable and others that are not, and this document hopes to illuminate the difference.
By enrolling in this course, each student assumes the responsibilities of an active participant in UMBC's scholarly community in which everyone's academic work and behavior are held to the highest standards of honesty. Cheating, fabrication, plagiarism, and helping others to commit these acts are all forms of academic dishonesty, and they are wrong. Academic misconduct could result in disciplinary action that may include, but is not limited to, suspension or dismissal. To read the full Student Academic Conduct Policy, consult the UMBC Student Handbook, the Faculty Handbook, or the UMBC Policies section of the UMBC Directory. The UMBC Student Academic Conduct Policy is also online.
As applied to our assignments, your team's obligations are do your own thinking, your own design, your own coding, and your own debugging. You should never let yourself be led by another student not on your team, or receive an amount of help which makes an assignment significantly easier. Conversely, you should never assist another student not on your team in a matter that would overly lead them or make their job much easier.
On our part, we will treat all of you with trust and respect. When alerted to any possible infraction, we will protect the honorable students' interests by investigating and prosecuting dishonorable behavior.
Assistance that is allowed and requires no citationThese things are encouraged and allowed at all times for everyone:
- Discussing any material covered in lecture or the text.
- Discussing the programming tools or development environments.
- Discussing the programming language and any libraries we are using.
- Discussing syntax or specifications.
For example: "Is comparing two strings case-sensitive? What does the keyword static do here?"
- Discussing the requirements of an assignment.
- Discussing general techniques of designing, coding, or debugging.
Sharing general-purpose advice like "I always test each function right after I finish writing it" or "When my programs crashes, I first look at the stack trace in the debugger" is fine.
- Any discussion between the student and a staff member. You are welcome to discuss any design, code, debugging, and details with the course staff. They are the best folks to talk to because they are knowledgable about all the material and know how to help you without giving away the farm. They also have the authority to give you definitive answers to your questions.
Collaboration that is allowed if documented
Whereas the discussions listed above are allowable, some discussions require citation. The difference between the two comes in what is being discussed and in how much detail. General topics (course materials, tools, language) may be discussed in any depth without citation. Discussing the particulars of the assignment you are working on requires citation. The particulars include such as things as the program's design, data structures, choice of algorithms, implementation strategies, testing, and debugging. Your submission must include the name of any student(s) with whom you had detailed exchanges and properly credit them. Some examples:
- Discussing the design of an assignment.
Design is a crucial part of the programming process, and we want you to learn to work through design problems on your own. Once you completed your own independently-conceived design, you may compare and contrast with a peer who has also completed their own design. You both must document this discussion and note any ideas taken away from it.
- Helping another student to debug a particular problem.
Two students not on the same team should not sit down and debug jointly at the same computer (see below), but a student could describe symptoms to a peer who responds with suggestions and hints (e.g. "it sounds like you might have forgotten to terminate the linked list" or "you might be accessing freed memory, have you tried commenting out all the free statements?"). This type of specific advice about how to debug your program should be cited.
- Sharing advice about testing.
For example, if your roommate shares some insight ("my program didn't handle the case where the input file didn't end with a newline") that you then use to improve your program's robustness, you should credit your roommate for providing you with that advice.
Collaboration that is NOT allowedWhereas discussion as described above is acceptable if cited, these discussions should never become so detailed that they involve jointly writing with another team or sharing passages of code. Your team's code must represent your team's original, independent work and it should not be developed in conjunction with or copied from another team. Here are specific examples of collaboration that is never allowed:
- Copying/sharing code.
This is the most blatant violation. You should not be in possession of anyone else's code nor sharing your team's code with anyone else. This applies to both printed and electronic copies.
- Using work from past semesters.
Using code from a former student's or team's work or previous semester's solutions is an obvious violation.
- Debugging with another person not on your team.
Sitting at the same computer and trying to find or fix someone else's bug is not permitted. It makes it too easy to look over the code and can result in (sometimes unintended) code-copying. Describing your problem to someone not on your team and asking for advice on how to track it down it is okay if cited, but you should do the actual debugging yourself.
- Using someone else's design.
Discussing your team's completed design with someone else and receiving feedback is okay if cited. However, just taking someone else's team's design as your own is not allowed. It is akin to taking someone else's outline for a research paper and basing your paper on that.
Above all you should use your common sense. If you suspect that what you are about to do is a violation, play it safe and ask a staff member first. When we confront a student with a case of suspected violation, an answer of "I thought it was okay; I didn't learn the course policies" is not justification.
The Honor Code is taken very seriously in this course and we have no tolerance for behavior that falls outside our boundaries for acceptable conduct. Please do your part in maintaining a community where academic work is done with a high standard of integrity!
Some parts of this document based on a similar collaboration policy for Stanford's CS courses.