## 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 **Readings.** Most classes will have a reading that you must read before coming to class, with online exercises that you should do and submit before class starts. The online exercises are designed to be practice for the in-class nanoquizzes, but are not graded for correctness, only for completion. There is no course textbook. **Nanoquizzes.** Every class meeting will begin with a short quiz on the required reading for the class, plus recent class meetings. Nanoquizzes are closed-book and closed-notes, with a 3-minute time limit. There will be approximately 25 nanoquizzes. Your lowest 5 nanoquiz grades will be automatically dropped, and you can make up missed nanoquizzes or low grades. See this page: [nanoquiz grading](nanoquiz-grading.html). **90-minute class meetings.** There are two 90-minute class meetings each week on Monday and Wednesday. You are expected to attend all class meetings and to participate actively in exercises and discussions. **60-minute class meetings.** There is one 1-hour class meeting each week on Friday. Your attendance will be required at some Friday classes; for others, attendance may be optional if you have already completed some related work. When a Friday class is optional, the conditions for missing it will be stated in the reading for that class. **Laptops required.** Classes will include multiple-choice questions and 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 **Problem sets.** To consolidate your understanding of the ideas from class, you will do five problem sets, PS0 to PS4, involving both design and implementation work. Problem sets will be done individually. **Code review.** As part of each problem set, 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 fewer 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 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 class times that will be reserved for this purpose. **Exam.** There will be one comprehensive exam, scheduled during class time several weeks before the end of the semester. The date of the exam can be found on the Stellar calendar. ## Grading The relative contributions of the various elements to your grade are: * **Quizzes: 20%.** Nanoquizzes are worth 10% total, and the comprehensive exam is worth 10%. * **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 completion of reading exercises, and by your participation in class and in the online Piazza forum. Letter grades are determined at the end of the semester. The default cutoffs are: a final average of 90 and above is an A, 80 and above is a B, 70 and above is a C. These boundaries may be adjusted downwards if necessary because of the difficulty of the assignments or quizzes, but the boundaries will never be adjusted upwards, so a final average of 90 is guaranteed to be an A. The boundary adjustment is done heuristically, and there are no grade quotas, no grade targets, and no centering of the class on a particular grade boundary. Every student is considered individually in the final grading meeting, judging from their entire performance in the course. A single bad mark in an otherwise consistent record will often be discounted. ## Problem Set 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 an instructor'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 and Public Sharing See this page: [collaboration and public sharing](collaboration/index.html). ## 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 on [Piazza], ... ask an LA during [lab hours][office hours], ... ask a TA during [office hours]. **For group project questions** ... ask your group members, ... or ask your TA mentor. **For questions about course content or to give feedback about the class** ... ask an instructor. **For special requests and concerns** ... ask a private question on [Piazza]. [Stellar]: http://stellar.mit.edu/S/course/6/fa14/6.005 [Java API docs]: http://docs.oracle.com/javase/8/docs/api/ [Piazza]: https://piazza.com/class#fall2014/6005 [office hours]: http://web.mit.edu/6.005/www/fa14/office-hours/