M.I.T. DEPARTMENT OF EECS

6.033 - Computer System Engineering Handout 2 - February 2, 1999

Assignment 1: February 2 through February 9

Each week you can expect to find an assignment like this one on the 6.033 home page, telling you what you should read over the course of the following week. Occasionally we will be organized enough to predict the readings a few days beyond the next Tuesday. Numbered readings, such as "reading #2," refer to materials in the packet you pick up from the EECS Instrument Room (38-501).

Each week you are expected to complete a reading report. The reading report is a short (one page) written report due at the beginning of every Tuesday recitation. The specific topic to be addressed in the report will be given on the previous week's assignment sheet. In recitation you should be prepared to talk about the whole paper, not just the particular point of the writing assignment. Note that we strictly adhere to the single-side, one-page limit. This forces you to prioritize issues and write concisely.

For Lecture: Wednesday, February 3

Read Saltzer, Chapter 1 (reading #3), and begin reading the paper by Simon, "The Architecture of Complexity" (reading #4).

For Recitation: Thursday, February 4

Finish reading Simon, "The Architecture of Complexity" (reading #4). Simon discusses the power of hierarchy using an astonishing variety of examples from many fields. As a personal exercise, after reading the paper, you may want to identify two examples of the use of hierarchy in Project Athena, and understand how hierarchy provided significant leverage or advantage.

In addition, read Gabriel's paper (reading #2). This is a lightweight paper, but makes a thought-provoking point. In general, we will have at most one heavy-duty technical paper per recitation, sometimes accompanied by an easy-to-read paper with up-to-date information, a thought-provoking point, an issue important to society, or high entertainment value.

For Special Lecture: Friday, February 5

This lecture is provided by the staff of the Writing Program and is intended to help you do a better job on weekly one-page reports. In preparation for this lecture, read Gopen and Swan, "The Science of Scientific Writing" (reading #5).

For Lecture: Monday, February 8

Read Saltzer, Chapter 2 (reading #6).

For Recitation: Tuesday, February 9

Read the Leveson paper (reading #7) and write a one-page reading report that addresses the question on "Safe Code Reuse":

On page 39 (bottom of the third column), Leveson and Turner state that code reuse often leads to safety problems. "Rewriting the entire software to get a clean and simple design may be safer in many cases." Explain one or two changes in the development of the Therac that would have made this statement false. That is, what would you have done differently as a developer of the Therac to make code reuse safe. Think about the conditions where the statement may apply -- and the conditions where the statement makes no sense.

Remember, use exactly one side of one sheet of paper for your report. We care about conciseness more than the amount of content. Since you will not be able to address every issue in one page, you will have to select only your best arguments for the one-pager. This assignment is due in recitation today.

Leveson's paper on-line: http://ei.cs.vt.edu:80/~cs3604/lib/Therac_25/Therac_1.html

Browse the 1998 6.033 web pages for examples of good writing on one-page reading reports. Also, please check the 6.033 FAQ for formatting instructions.

After reading Leveson's paper you may be flabbergasted by how badly the Therac-25 systems were designed. The next reading (#8, Lampson's "Hints for computer system design") has a number of suggestions that often lead to better systems. If you have time and energy left, browse through this thoughtful paper. You might want to ask yourself which hints the designers of Therac-25 violated. Don't worry if you do not fully understand this paper yet (or if you only have time to skim it); it will be assigned again at the end of the term.

System aphorism of the week

There is no such thing as a small change in a large system.
Go to 6.033 Home Page Questions or Comments: 6.033-tas@mit.edu