15-412 Syllabus

Course objectives

The goal of this class is for students to acquire hands-on experience with operating-system code as it is developed and deployed in the real world. Groups of two to four students will select, build, install, and become familiar with an open-source operating system project; propose a significant extension or upgrade to that project; and develop a production-quality implementation meeting the coding standards of that project. Unless infeasible, the results will be submitted to the project for inclusion in the code base.

Variations on this theme are possible at the discretion of the instructor. For example, it may be possible to work within the context of a non-operating-system software infrastructure project (window system, web server, or embedded network device kernel) or to extend a 15-410 student kernel. In some situations students may work alone. Group membership and unit count (9 units versus 12) will be decided by the third week of the semester.

Contributing to a real-world project will involve engaging in some mixture of messy, potentially open-ended activities such as: learning a revision control system, writing a short design document, creating and updating a simple project plan, participating in an informal code review, synthesizing scattered information about hardware and software, classifying and/or reading large amounts of code written by various people over a long period of time, etc.

When possible, it may be advantageous for students to register for the class with partners with whom they have an existing working relationship.

Prerequisites

The prerequisite is 15-410, Operating System Design & Implementation. Students not meeting the prerequisite must receive the approval of the instructor, as the 15-213/15-410 sequence really provides key preparation.

In addition, you should be excited by the opportunity to define a project, design a solution to a somewhat open-ended problem. You should not be deterred by the likelihood you will need to glean information from dense technical documents or hunt down complicated bugs. Unlike assignment-based courses, you will not be implementing something which has been tested by N semesters of previous students...

Course Activity and Grades

Class attendance will be very important. We will meet for project planning, to discuss various technical topics as they arise, and to discuss pre-assigned readings (from the textbook and academic papers). If you will be unable to attend class on a particular day, contact the instructor in advance.

Here is a tentative, approximate grading breakdown.

Cutoff points for grades will be set by the course staff based on an examination of the quality of the work turned in by students near the border. Likewise, individual students, especially those near a cutoff, may receive adjustments upward or downward based on factors such as quality improvement, final exam scores, dramatic differences between partners, or other circumstances relevant to the estimation of the staff of which grade best represents the student's work.

Team Programming

Most of the programming effort will be in a team-programming context, to give you experience with the design strategies, coding standards, documentation practices, source control techniques, and people skills you are likely to need in both industry and academia. Here we differentiate between team programming and software engineering in that we will not cover requirements analysis, release staging, defect management, and other life-cycle issues.

You may experiment with various development styles. Some students explore "Extreme Programming", and others have had good experiences with Pair Programming (Williams & Kessler).

You should probably discuss your committment to the class with potential partners. For example, if it is spring semester and you are planning to graduate, a first-year drama student auditing the class might not make the best partner for you.

Academic Conduct

In general, collaboration is good when it furthers genuine learning and bad when it doesn't. Meanwhile, plagiarism (using the work of others without giving them appropriate credit) is definitely bad. This principle can often help you decide between good collaboration and bad collaboration: if you would feel bad about accurately giving credit for part of your program, then it probably shouldn't have been created however it was. Another good rule is that if you're not sure whether something is ok, you should ask the course staff.

Acting in accordance with all relevant software licenses, open source and otherwise, throughout the course of the project will of course be mandatory.

Also, in general, we expect you to behave honestly and according to high standards of academic conduct.

[Last modified Monday December 30, 2019]