Contents:
The course web site is http://www.mit.edu/~6.170/.
All students must run student-setup.pl by 9pm on Wednesday, February 8 (the day of the first lecture), or they will not be able to take the class.
You also must register with the MIT Registrar. You do not need to be in the same recitation as others in your final project group.
| Lecturers | Michael Ernst | 32-G718 | 253-0945 | mernst@csail.mit.edu |
| Saman Amarasinghe | 32-G778 | 253-8879 | saman@csail.mit.edu | |
| TAs | C. Scott Ananian | 32-G728 | 253-7710 | cananian@mit.edu |
| Natan Cliffer | natan@mit.edu | |||
| Philip Guo | pgbovine@mit.edu | |||
| Tucker Sylvestro | t@csail.mit.edu | |||
| Matthew Tschantz | tschantz@mit.edu | |||
| Vincent Yeung | vshyeung@mit.edu | |||
| LAs | ||||
| David Glasser | glasser@MIT.EDU | |||
| Katherine Hollenbach | kjhollen@MIT.EDU | |||
| Eric Lieberman | ericl@MIT.EDU | |||
| Scott Ostler | sostler@MIT.EDU | |||
| Clayton Sims | ctsims@MIT.EDU | |||
| Robert Toscano | rtoscano@MIT.EDU | |||
| Stephanie Yeh | syeh@MIT.EDU | |||
| Course Secretary | Maria Rebelo | 32-G715 | 253-1550 | mr@csail.mit.edu |
Mail sent to 6.170-staff@mit.edu
will reach the lecturers, TAs, and LAs.
Mail sent to 6.170-lecturers@mit.edu
will reach the lecturers.
Mail sent to 6.170-tas@mit.edu
will reach the teaching assistants.
Mail sent to 6.170-las@mit.edu
will reach the laboratory assistants.
TAs will schedule office hours and locations by the end of the first week of class. Please visit your TA (or another TA, if necessary) during their office hours if you have anything you'd like to discuss about the course or course materials. Please see the TA Office Hours for the locations and times of office hours.
LAs will schedule LA hours held in designated clusters. Please feel free to work in the cluster so you can talk to them in person when you have questions about Java or other technical details. Time permitting, they also monitor the forum while on duty, but they give priority to students who visit them in person. Please see the LA Lab hours for an up-to-date list of hours.
The lecturers are available by appointment but do not have fixed office hours.
When solving your assignments, the laboratory assistants should be your first resource for problems with your Java code or the Athena environment. For other questions, the LAs may be able to help you with advice or information, but the answer of a TA or lecturer is authoritative. Your TA can answer most questions about the course. The LAs or TAs may choose to escalate your questions to the head TA or the lecturers; you may also do so yourself if you do not receive an answer.
Here are some examples of questions appropriate for various staff members. Naturally, you shouldn't ask a question unless you have first tried to find the answer yourself. When asking a question, be sure to say what you have already tried to do to solve the problem; that way the staff won't waste its time and yours repeating something you already know.
These books are available at Quantum Books and Amazon.com, among other retailers.
The following books are required:
Some other excellent books you should consider for your reference library on software engineering are:
6.170 has lectures Monday, Wednesday, and Friday from 1-2 in room 32-123, and recitations on Thursday at 10, 11, 12, 1 or 3.
Recitation Section Locations and Times (Thursdays):
The registrar will assign you a recitation. Please attend that recitation.
| Section | Instructor | Location |
|---|---|---|
| 1 | Matthew Tschantz | 36-155, 10am |
| 2 | Vincent Yeung | 26-328, 11am |
| 3 | C. Scott Ananian | 36-112, 12pm |
| 4 | Philip Guo | 5-234, 1pm |
| 5 | Tucker Sylvestro | 26-302, 3pm |
| 6 | Natan Cliffer | 26-204, 3pm |
Recitation section information will be distributed by email and on the web on the evening of Wednesday, Feb 8.
While 6.170 is a lab class, lab work will be performed on your own time either on Athena or using your own personal machine. Since both lectures and recitations in 6.170 tend to focus on conceptual material pertaining to software engineering rather than particulars of how to use the Java language, this term we are offering optional laboratory exercises. These sessions are optional and ungraded, but they will help you to understand and use the Java language and tools more effectively.
Lab sessions will involve a one-hour exercise that introduces you to some tool (such as editing environments, compilers, debuggers, and profilers) or to some aspect of the Java language (such as inheritance and the Swing library). LAs will be on hand to help you during their lab hours. You can work in pairs or groups on the labs to help you learn from each other: your styles, little tricks about programming, using the environment, etc. You can also get to know other students; we encourage you to work with many different people.
Each student will meet personally with his or her teaching assistant for 15 minutes each week to go over the completed problem set. The teaching assistant will have looked briefly at your work in advance, and will make a grading decision after the meeting. The purpose of the meeting itself is to give you a chance to explain your work, to answer questions about it, and to receive feedback. You should not expect to receive written comments in addition. Your teaching assistant will schedule the weekly meeting with you.
The first grading meeting will occur for Problem Set 1. There is no grading meeting for Problem Set 0. Students are required to attend grading meetings, and we reserve the right to penalize a student's problem set grade for missing a meeting.
There will be two one-hour quizzes during class time; see the class schedule.
| Individual Work |
TA discretion (including recitation participation) |
5% | 70% |
| Problem set 0 | 1% | ||
| Problem set 1 | 6% | ||
| Problem set 2 | 6% | ||
| Problem set 3 | 6% | ||
| Problem set 4 | 6% | ||
| Problem set 5 | 6% | ||
| Problem set 6 | 10% | ||
| Quiz 1 | 12% | ||
| Quiz 2 | 12% | ||
| Group Work | Final Project | 30% | 30% |
We will make every effort to standardize TA grading policies, but we reserve the right to normalize grades across recitation sections to account for remaining disparities.
As an an example, suppose that you have a problem set that is due on Thursday at 5:00pm, but you need extra time. You tell your TA by 5:00pm on Thursday, and you can turn in that problem set on Friday at 5:00pm. You cannot use slack time for PS0, the final project, or returnins. Also, slack days are atomic; you cannot split up a slack day and submit each of three problem sets 8 hours late.
The Departmental Guidelines Relating to Academic Honesty require that we inform you of our expectations regarding permissible academic conduct.
It is our intention that each student gains the full benefit of 6.170 and achieves a full understanding of the course material. However, we recognize that some students benefit from discussions with other students. Therefore, we permit limited collaboration on 6.170 assignments.
It is your responsibility to satisfy both the letter and the spirit of the rules. If any part of this policy is not clear, or if you have any questions or concerns, ask a member of the course staff for clarification. Violating the collaboration policy may result in failing the class and/or other penalties. We will use technological and other means to detect cheating.
For the individual problem sets in the first half of term, you must write up all solutions on your own. However, you are permitted to discuss 6.170 assignments with other people. No materials you bring to or take away from such meetings may be turned in as (part of) your solution. Your solution must list all other people with whom you discussed solving the assignment.
For example, it is permissible to discuss testing strategies with another student, but you may not view another student's testing code. As another example, you and other students can sketch out an algorithm or design together, but you must destroy any written materials from your meeting and work from your understanding (that is, your memory).
No other 6.170 student may view your solutions; this includes your writing, code, tests, documentation, etc. It is a violation of the collaboration policy to send more than 5 lines of code to the forum, zephyr instance, or other location accessible to other students. (You are better off talking to an LA in person anyway.) It is a violation of the collaboration policy to permit anyone besides the 6.170 staff and yourself read-access to your ~/6.170 directory or any other location where you keep 6.170 code. (If you need to copy code to your home computer, use CVS.)
You may not view anyone else's solutions (from this semester or previous semesters). You may not refer to code or specifications in materials from previous offerings of 6.170 ("bibles"), nor to material on the Internet that solves the problems. You may not transcribe a solution from any other source. (For instance, no one may dictate code to you, nor send you snippets of code for your use, nor create a solution for you to memorize and later type in.)
As an exception to the prohibition against viewing another student's problem set, you are permitted to assist another student with tool-related problems (such as difficulty using Eclipse or CVS), even if such assistance results in incidental viewing of snippets of code. Each student is expected to debug the problem set code individually, however.
Your solutions may use code from the standard Java libraries and from libraries offered for your use by the 6.170 staff. All other code in your submitted work for the individual assignments must be of your own creation.
You may use conceptual material that you obtain from textbooks, the Internet, previous offerings of 6.170, and other sources. For instance, Introduction to Algorithms by Cormen, Leiserson, Rivest, and Stein is an excellent resource for looking up algorithms. If you use any material from an external source, you must credit it clearly in your documentation.
For the final project, you are encouraged to collaborate with your teammates on all aspects of the work, although every member of the team is expected to contribute a roughly equal share to the design and implementation. Your design and the bulk of your implementation must be unique to your group. However, you may reuse code from your work earlier in the semester or from other sources. (For instance, you might use a specialized image library to create a graphical effect.) Code from external sources may not implement core functionality of the project. Any code you submit must be properly attributed and must be coded, documented, and tested to 6.170 standards.
Handouts will be distributed on the class web site. Announcements will be posted as Messages of the Day on the class website and will be emailed to all students.
Students in 6.170 are required to submit the implementation part of the problem sets electronically, as the problem sets will specify. See the Problem Set Submission document for details about the procedure for turning in a problem set.
All code you turn in must compile. It must also run when called in the manner specified by the problem set, or it will not receive credit for correctness. TAs will not adjust your output formats or otherwise debug your programs to try to get them to run. You will be given example input and output files, and often full test suites as well, in order to test your own programs before submitting them.
Your documentation must clearly indicate any shortcomings of your program. If your code does not compile, or if certain functionality is missing, and your documentation does not clearly and prominently indicate as such, then you will lose points for the omissions (as well as for the defect itself).
Diagrams which you turn in must be readable. While we will not be grading on artistic merit, if it is not easy to see what is happening, then you have not successfully conveyed the relevant information, and you will be graded accordingly.
For many of the problem sets we will provide you with a detailed specification for the behavior of the code that you will write. It is imperative that the program you write conform precisely to these specifications. This means that your program should not write anything to either standard out or standard error other than precisely what is specified. You should verify that the spelling, phrasing, or punctuation conforms to the specification as your program will be subjected to automated testing. The output of your program should furthermore be deterministic: it should not vary from run to run when presented with the same input.
In addition to providing specifications for the behavior of your program, we will often provide specifications for certain classes. For such classes you are free to add private fields, methods, and constructors, but unless otherwise specified you may not add public, protected, or default-access (package) fields, methods, or constructors.
The test suites which you include with your program should run in under a minute when testing your implementation.
After any code you submit for problem sets 1-4 has been graded, you will submit a corrected version of the code (even if you received complete correctness credit for the original submission). The resubmitted programs are graded on correctness only, and there is no partial credit. You don't have to expand documentation, fix style problems, etc. (although doing so might simplify the task of correcting your program). The regrade is worth a fourth of the total grade for the assignment, so failure to resubmit your program will mean you can't get more than 75/100, even if everything else was perfect.
For example, suppose that student Tortoise received 60/75 points on the first problem set submission, then later submitted a correct program, and further suppose that student Hare received 70/75 points on the first problem set, but did not bother to fix the problems in the submission. Then after adding the returnin points, Tortoise's final grade would be 85/100, while Hare's would be 70/100.
The automated returnin results are not intended to replace, or even to supplement, your own test cases. They merely help the staff evaluate the correctness of your solution. You only get to see the first failure because we want to find out how many errors remained in your program when you believed it was completely correct. It only runs periodically because you shouldn't need or expect an instantaneous result (the staff does not encourage last-minute work). These mechanisms, plus having only 3 free tries, encourage you to get your program test suite right. If you are having a lot of trouble with a piece of code, consider throwing it out and starting from scratch; that might be a more effective way to get correct, functional code than a long debugging cycle.
See the Problem Set Submission document for details about the procedure for turning in (and re-turning in) a problem set.
We will return graded assignments to you within one week from when they are due, or, in the case of late turnins, from when you submit the assignment.
To complete assignments as efficiently as possible, and to derive the most benefit, we recommend that you:
