E6998-2: How to Make Reliable Software
Fall 2008 -- Junfeng Yang
- Location: ENG 253
- Time: Wednesday 4:10-6:00pm
- Credits: 3 units
- Instructor: Junfeng Yang
- Office Hours: After class or by appointment
- Address: 460 CSB
Students are expected to have done some
significant programming, for example, via taking an advanced
programming course (COMS W4118 OS, COMS W4115 PLT, etc) or working
Despite our increasing reliance on computing platforms, making reliable
software systems remains difficult. Software errors have been reported to
take lives and cost billions of dollars annually. Making reliable
software is one of the most important problems in computer science. In
recent years, this problem has drawn huge attentions from researchers in
systems, software engineering, and programming language
communities. A number of automated techniques have been developed to
increase software reliability. In this course, we will study the most
practical and most important of these reliability techniques.
Specifically, we will study:
In addition, we will have the opportunity to hear guest speakers who have
built large software systems or effective checking tools talking about
their first-hand experiences.
- Practical bug-finding techniques. We will learn effective
techniques that have found thousands of serious errors in large systems,
as large as an entire Linux kernel.
- Fault isolation and recovery. We will learn techniques to
prevent a single component failure from crashing an entire system and to
completely recover from such component failures.
- Automated debugging. Debugging (i.e. finding the root
cause of a bug) is usually a painful manual process; we will learn
techniques to make debugging more automatic and less painful.
- Concurrency. CPUs are getting more cores; the implication
is that multi-threaded programs will be the mainstream. To better
understand the errors in multi-threaded programs (e.g. races and
deadlocks), we will study their characteristics; we will also study
effective techniques to find these concurrency errors.
- Other reliability techniques. For example, we will learn
the underlying mechanisms of a popular dynamic tool Valgrind and a
commercial virtual machine VMware.
Course Format and Student Workload
This course will center around two entities: readings and a final
project. In the first half of most every class meeting, students
briefly present a few papers (as assigned); in the second half, we will
discuss the papers in depth. For the in-depth discussions to be possible,
you will have to read the papers carefully before class. To help achieve
this, you will have to write a review of each paper and turn it in before
class. The real key to the class will be your final project: a
mini-research project on the topic of your choice. Though I will provide
some suggestions, you are strongly encouraged to come up with a topic of
your own (after all, that's what research is all about). More details
will be available below in the weeks to come.
The course readings include a list of papers selected from top system,
software engineering, and programming language conferences. You can find
the papers at the Course Syllabus page. You have
three basic responsibilities for the papers covered in the course.
- Read the assigned papers carefully, before class. One of
the main goals of the course is to have interesting in-class discussions
so that students can hopefully understand the topics better. To this
end, I recommend you read each paper at least three times: twice very
carefully, the last time focusing on the hard parts.
- Write a short review of each paper. The review should
include at least three good technical points of the paper, and one
shortcoming that can be improved. The review should not exceed
one page in length. All reviews will be made available to students and
will serve as the starting seed of the in-class discussion. Turn in
your review via email to me (junfeng@cs) before 9am on the day
of the class where we discuss the paper, with the class and date in
the subject line (e.g. E6998-2 Reading 9/10). Reviews should be
in plain text so I can easily parse them with any mailer. You
are free to form discussion groups, but your review must
be individually written.
- Present papers. Each student should present roughly two
papers they choose; the exact number depends on the actual class size.
Each presentation should be within 25 minutes to cover the key points of
the paper. Student presenters should get their slides ready and show
them to me two days before they give presentations (i.e. on the Monday
of the week when they present). I will bring a sign-up sheet to the
first few class meetings.
The final project is the key of the course. It must involve new research
and have the potential of being published in a major conference. It can
be a novel technique, an improvement to an existing technique, an
application of a technique to a new domain, etc. I will provide a list of
project suggestions for you to pick from, although you are strongly
encouraged to think of a project on your own, which I can help to refine.
You can work on your project alone or with a partner; I will not allow a
team of more than two students. The timeline of the project is as
- 10/1 -- Proposal. Choose a topic and submit a 1-2 page
proposal (due before class). You will give a 5-10 minutes presentation
of your project proposal in class.
- 11/12 -- Midterm project report. Give a 10 minute
presentation on the progress of your project.
- 11:59 pm 12/16 -- Final report. Submit a 6-page final report,
your source code, and all relevant data. Late submission = no
- 4:10-7:00 pm 12/17, ENG 253 -- Project presentation and demo.
- Project: 50%
- Proposal: 5%
- Midterm presentation: 5%
- Final report: 20%
- Project presentation and demo: 20%
- Paper review: 25%
- Paper presentation: 15%
- Class participation: 10%. To encourage active
in-class discussion, I will assign 10% of the grade to class
There is no required textbook; all relevant materials will be made