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

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).

Grading will be based to some extent on class participation,
but primarily on the accomplishments and code quality of the
project.

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.

Hazards

Medical issues

If you experience a medical problem which disrupts your studies,
please go to Student Health Services (or another medical provider)
and have them emit some piece of paper
describing the situation and what you are medically required
to do about it. If there are privacy concerns, we will accept
a firm statement of the restrictions on your activities without
a description of the condition itself.

Please do not come to the course
staff and tell us that you've been too sick to attend class and
code for two weeks but that it hasn't "been bad enough" to merit
medical attention. If nothing else, it probably has been
"bad enough" for your partner.

You may prefer to disclose an ongoing medical situation to
Mark Stehlik and/or Catharine Fichtner (or your home department's
undergraduate chair and/or administrator).
They can then take care of notifying all of your instructors.

Partner problems

Please try to avoid having partner trouble. Seriously! Share
your hopes before they turn into concerns, your concerns before
they become problems, and your problems before they inflate into
crises. Also, if you are experiencing a partner disaster, please
try to inform the course staff some time before the
due date.