General Information & FAQ

The prime objective of 6.031 is learning how to write code that is:

• safe from bugs (SFB),
• easy to understand (ETU), and
• ready for change (RFC).

Every idea and skill in the course is calibrated against those goals. Specific objectives include:

• an understanding of key software engineering ideas, including interfaces, representation independence, specifications, invariants, abstract data types, design patterns, and unit testing

• the ability to apply these ideas to design, implement, and test a small- to medium-scale software system (up to a few thousand lines of code, multiple modules), by:

  • defining abstract data types
  • writing specifications for operations
  • choosing concrete representations and defining abstraction functions and representation invariants
  • writing a comprehensive suite of unit tests
  • creating regular expressions and grammars for parsing input
  • creating client-server programs that adhere to a given protocol
  • designing a concurrent program using concurrent language features and library types
     

• an understanding of general programming-language concepts such as static typing, exceptions, access control, interfaces, and equality, and ability to use Java as a particular example language with those concepts

• the ability to use modern programming tools (e.g. Eclipse, Git, JUnit) and modern programming technologies (e.g. I/O, regular expressions, network sockets, threads, GUIs)

• experience working in a project team

Class meetings. There are three 90-minute class meetings each week on Monday, Wednesday, and Friday. You are expected to attend all class meetings and to participate actively in exercises and discussions.

Laptops required. Classes will include programming exercises that require a laptop set up with the course tools. 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. We encourage you to take advantage of the remote learning iPad loaner program as well.

Readings. Most classes will have a reading that you must read before coming to class, with online exercises that you should do by 10:00pm US Eastern time the night before the class. The online exercises are designed to be practice for the in-class nanoquizzes, but are not graded for correctness, only for effort. 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. The nanoquiz is part of the grade for each class, along with reading exercises, in-class programming exercises, clicker questions, and other activities.

The lowest 5 classwork grades are automatically dropped, so you are automatically excused from up to five classes. You can also make up missed or low classwork grades. More info: details of classwork grading and makeup.

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. More info: collaboration on problem sets.

Code review. As part of each problem set, there will be a 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: code reviewing.

Iteration. Each problem set will have two submissions, alpha and beta. The alpha submission will be graded and will be subject to code review. The beta submission is due a few days after you receive feedback on alpha. You will be expected to iterate on your design and implementation, fix any failed test cases, and revise your code based on code review feedback.

The beta submission must address all the code reviews received by the alpha submission. More details here: how should I address my code reviews?

Since the beta submission 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.

Slack days. 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 alpha deadline or beta deadline or both. You can use at most 2 slack days for a given deadline. After your deadline has passed, whatever has been pushed to your repository on github.mit.edu 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³ dean for more extension, and your circumstances will have to be extreme to justify the special request.

Project. You will complete a group software development project at the end of the semester, in a team of three students. Every 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.

Project teams. Before the project, you will be able to request one or two teammates you would like to work with. If you don’t already know other students in 6.031 this semester, we hope that working together on in-class exercises will give you the opportunity to find potential project partners.

Team meetings. During the project, you and your project team will meet with your TA to discuss the work. Your TA will assign a grade based in part on these meetings. Team meetings will usually be scheduled during class times that will be reserved for this purpose.

Quizzes. There will be two quizzes. Quiz 1 is shown on the course calendar, and Quiz 2 will be held during the final exam period, so its date and time will be shown on the final exam schedule.

Each quiz will be comprehensive, drawing on any topics covered up to that point in the course, so e.g. Quiz 2 may include topics that were already covered on Quiz 1.

Both quizzes are an hour long.

This topic has its own page: collaboration and public sharing.

The relative contributions of the various elements to your grade are:

• Quizzes: 24%. Quiz 1 is worth 12%, and Quiz 2 (scheduled during the final exam period) is worth 12%.
• Problem sets: 54%. PS0 is worth 6%, and PS1-PS4 are each worth 12%.
• Code review: 6%. Judged by regular participation in code review and providing substantive, useful comments.
• Project: 5%.
• Classwork: 11%. Reflects your continuous participation in the course. Determined by effort on before-class reading exercises, grade on nanoquizzes, and effort on in-class exercises.

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.