## Objectives See the [6.005 Curricular Goals Map] giving a dynamic graphical display connecting the class outcomes with the outcomes of other subjects in the Course 6 curriculum. [6.005 Curricular Goals Map]: http://6004.mit.edu/gmap/public.html?focus=6.005 ## Course Elements **Lectures.** There are three 1-hour lectures each week. You are expected to attend all the lectures and to participate actively in discussions. **Recitations.** There are two 1-hour recitations each week. You are expected to attend one recitation each Tuesday & Thursday and participate regularly. Though we ask you to use Stellar to select a primary recitation slot, you are allowed to attend different slots occasionally. Recitations will contain assignments that will be checked off after each recitation; if the recitation covers a topic you already are an expert in, you may submit the recitation exercises in lieu of attending, though doing so may cause you to miss some important enrichment. **Laptops required.** Recitations (and occasional lectures) will have programming exercises that require a laptop. If you don't have your own laptop and you need to borrow one, IS&T has a [laptop loaner program] that will lend you one. [laptop loaner program]: http://ist.mit.edu/services/hardware/lcp **Text.** There is no course text, but lecture and recitation notes will be posted online. **Problem sets.** To consolidate your understanding of the lecture ideas, you will do five problem sets, involving both design and implementation work. Problem sets will be done individually. **Code review.** After each problem set submission deadline, there will be a 2-day code-reviewing period when other students and staff will give you feedback about the code you submitted, using a web-based system. You will be expected to participate in this process by reviewing some of your classmates' code. More details about objectives and guidelines for the code reviewing process are found in a separate document on this web site: [code reviewing](./codereview.html) **Beta and Final Submission.** Each problem set will have beta and final submission. The beta submission will be graded by an automated tester, and will be subject to code review. The final submission is due a week later. You will be expected to fix any failed test cases and revise your code based on code review feedback. The beta submission is worth 40% of the problem set grade, and the final is worth 60%. The final submission must address all the code reviews received by the beta submission -- all the human comments plus all the automated checkstyle comments that are marked #important. You can address a code review either by changing the code to reflect the review or by including a source code comment in your code that explains why the code wasn't changed. If code reviews are unclear, you can discuss them with the reviewers by replying on the Caesar system, but you still must edit your own code in reaction to the review. A grader will check the submission and deduct points if it hasn't addressed the code reviews. Since the final submission inevitably happens after code review for the problem set, it's understood that you've looked at other students' written solutions, and been inspired by other ways to solve the problems. You must be exceedingly scrupulous, therefore, in not using those written solutions during your revision. Both your original code and your revised code must be your own. Looking at other students' answers to the problem set while you are revising your solution will be considered a violation of the collaboration policy. **Project.** You will complete a group software development project, which happens in three phases during the semester. The project will be done in teams of three students, and you'll have a different team for each phase of the project. The rules for team composition are as follows: * No two students can be on the same team for more than one phase of the project * For every phase, there will be a deadline for you to notify us of the composition of your team. Any student who does not have a team by the deadline will be assigned to a team by the course staff. After the deadline, any team containing less than three students, or that includes students that have worked together in previous projects will be dissolved, and its members will be reassigned to other teams. * When the number of students is not divisible by three, it will be up to the staff to decide whether to allow one four-person team or two two-person teams. * If a member of your team drops from the course (or simply disappears), inform your TA as soon as possible. Each team member is required to participate roughly equally in every activity (design, implementation, test, documentation), and we may ask for an accounting of what each team member did. A single grade will be assigned to all members of the team. **Team meetings.** During the project phases, you and your project team will meet with your TA to discuss the work. Your TA will assign a grade based in part on this meeting. Team meetings will usually be scheduled during lecture or recitation times that will be reserved for this purpose. **Quizzes.** There will be four quizzes, on dates specified on the course calendar. Each quiz will be comprehensive, drawing on any lecture and recitation topics covered up to that point in the course, so e.g. Quiz 2 may include topics that were already covered on Quiz 1. ## Grading The relative contributions of the various elements to your grade are: * **Quizzes: 20%.** All four quizzes have equal weight. * **Problem sets: 40%.** PS0 is worth 4%, and PS1-PS4 are each worth 9%. * **Project: 30%.** Each phase of the project is worth 10%. * **Code review: 5%.** Judged by regular participation in code review and providing substantive, useful comments. * **Participation: 5%.** The participation grade will be determined by your participation in recitations, the online Piazza forum, and lectures (roughly in that order of precedence). ## Lateness and Extensions To give you some flexibility for periods of heavy workload, minor illness, absence from campus, and other unusual circumstances, you may request limited extensions on problem set deadlines, called slack days. Each slack day is a 24-hour extension on the deadline. You have a budget of **10 slack days** for the entire semester, which you may apply to any combination of problem sets, on either the beta deadline or final deadline or both. You can use at most 2 slack days for a given deadline; after 2 days, whatever is in your git repository is what we will use for grading. You must request your extension before the problem set is due, by logging into the Caesar code-reviewing system and clicking on Request Extension. The system keeps track of your slack days and informs you how many you have left. Slack days are atomic; you can't chop them up into slack hours or minutes. If you choose to use a slack day because you're struggling with an assignment, **go to bed and sleep**, and get help in the morning. Seriously, that's why the smallest unit is a day. Slack days apply only to individual problem sets, not to team projects. If you have used up your slack days, or exceeded the 2-day limit for a single deadline, you will need a lecturer's permission and support from an S^3 dean for more extension, and your circumstances will have to be extreme to justify the special request. ## Collaboration In line with the Departmental Guidelines Relating to Academic Honesty, here are our expectations regarding collaboration and sharing. For the team projects, you are encouraged to collaborate with your partners on all aspects of the work, and each of you is expected to contribute a roughly equal share to design and implementation. You may reuse designs, ideas and code from your own work earlier in the semester (even if it was done in a team project with a different partner). You may also use material from external sources, so long as: (1) the material is available to all students in the class; (2) you give proper attribution; and (3) the assignment itself allows it. In particular, if the assignment says "implement *X*," then you must create your own *X*, not reuse someone else's. Finally, your team may not reuse designs, ideas, or code created by other teams, in this semester or previous semesters. Problem sets are intended to be primarily individual efforts. You are encouraged to discuss approaches with other students but your code and your write-up must be your own. You should not make use of any written solutions or partial solutions produced by others. Material from external sources can also be used with proper attribution, but only if the assignment allows it. You may not use materials produced as course work by other students in the course, whether in this term or previous terms, nor may you provide work for other students to use. During code review, you will see classmates' solutions to a problem set. While it is fine to take inspiration from their approach, do not copy their work. Copying work, or knowingly making work available for copying, in contravention of this policy is a serious offense that may incur reduced grades, failing the course and disciplinary action. ## Questions? {#who-to-ask} **Before you ask** ... try to find the answer yourself: search on [Stellar], or the [Java API docs], or [Piazza], or the web. **For problem set questions and debugging help** ... ask an LA in lab, ... ask an LA or TA during [office hours], ... ask on the course Piazza forum, ... or ask your recitation TA. **For group project questions** ... ask your group members, ... or ask your TA mentor **For questions about lecture content, to give feedback, and for special requests and concerns** ... ask a lecturer. [Stellar]: http://stellar.mit.edu/S/course/6/sp14/6.005 [Java API docs]: http://docs.oracle.com/javase/7/docs/api/ [Piazza]: https://piazza.com/class#spring2014/6005 [office hours]: http://web.mit.edu/6.005/www/sp14/office-hours/