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.

Textbook

Though the course will not center around a textbook as such, I would like to recommend Kernighan & Pike's The Practice of Programming, ISBN 0-201-61586-X, which should be available in CMU's bookstore.

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.

[Last modified Monday November 15, 2004]