Summarized by Gretta Bartels, Univ. of Washington |
Jerry Saltzer (Massachusetts Institute of Technology) |
In the first invited talk, Jerry Saltzer presented his engaging view of how software engineers and system designers should work to cope with complexity in large computer systems. First, Saltzer analyzed the sources of complexity. He explained that systems become unwieldy because their specifications call for a tremendous laundry list of objectives, but system designers lack principles for achieving so many goals simultaneously.
As a series of object lessons, Saltzer presented a series of engineering failures in increasing cost, from failed upgrades to the New York City traffic light system to the flopped British Stock Exchange project to a dragging project to modernize the U.S. Government's tax collection system. He discussed the causes of failure in each of these systems, pointing to the second system effect, designers trying to tackle too many goals at once, the mythical man-month phenomenon, oversight committee meddling, and more. Saltzer also discussed what he termed the bad news-good news diode: the tendency in large bureaucratic organizations to pass only good news up the management chain, so that the highest levels of the organization are the most deluded.
In the second part of the talk, Saltzer presented a series of principles for coping with the rampant complexity problems plaguing systems development today. He suggested that system designers plan for iteration in the design process. Building iteration in allows bad ideas to fail sooner in the development cycle, making them less costly and easier to weed out. He also pointed out that novelty is sometimes included just for novelty's sake, and that managers must be strong enough to pick and choose their complexity, to say no to strong-willed designers who want their own good ideas included. Finally, Saltzer implored the audience not to allow their own systems to become case studies in future versions of his talk.
In the lively question and answer session that followed the talk, Ken Birman asked why it is that some complex systems do succeed. Saltzer replied that these systems were usually built up in small steps, with each intermediate system stable and functional. Dave Tennenhouse pointed out that virtually all of the examples in the talk were from the commercial, industrial, and governmental sectors. How can academic researchers benefit from the advice in this presentation? Tennenhouse pointed out that the Alto project at PARC and an MIT project whose manager's name he couldn't quite remember (to much laughter) were good examples of complex academic research projects. Saltzer's answer was that academic projects often have different goals, such as the spread of ideas, so a completely stable system may not be necessary, but that otherwise his principles transfer well. Finally, John Wilkes pointed out to the amusement of the audience that since we learn so much more from failures than successes, all graduate students should be forced to work on a large failing project.
Thumbnail slides from this presentation are at: http://web.mit.edu/Saltzer/www/publications/Saltzerthumbnails.pdf
Butler Lampson (Microsoft Research) |
In Butler Lampson's invited talk, he treated the SOSP community to his view of computer systems research over the last twenty years, and then presented a charge for the next ten. Lampson started by setting a bit of context for the rest of his comments. He pointed out that the most important context for computer systems research is Moore's Law, and that people often lose sight of the enormity of the law's implications.
Next, Lampson presented his views of what successes our community has enjoyed. He presented a slide with a "Yes" column and a "No" column, and to demonstrate his even-handedness, he marked with a red dot the areas in which he'd worked. The audience laughed appreciatively at the prevalence of the red dots speckling the "failure" column of the slide. Among the successes he listed virtual memory, transactions, GUIs, the web, and algorithms; the failures included capabilities, fancy type systems, formal methods, software engineering, and distributed computing. He then spent several minutes explaining his list of failures before too many members of the audience could become too incensed, and went on to share some "Maybes" which may yet pan out.
After completing the Yes, No, and Mabye lists, Lampson went on to say that because our community didn't invent the world wide web, we should be very embarrassed and take a long look at ourselves to figure out why we missed that opportunity. He postulated that we didn't invent it because it's too simple.
For the future, Lampson presented three issues: simulation, communication, and control. We've used simulation throughout the history of computing, but there are still a lot of things we don't know how to simulate: for example, clothing, cities, and complex organisms. We are doing pretty well with communication these days, but we're not yet doing a good job of getting all the information in the network where it's needed. Finally, for control, the canonical application used to be robots, but these days we have more interesting applications like MEMS and smart paint. There are also a number of programming challenges, such as dealing with uncertainty sensibly and harnessing the concurrency implicit in tomorrow's multiprocessor chips. Systems challenges include writing and meeting specifications in a measurable way and creating credible system simulations and analysis.
In the question and answer session, Jeff Mogul pointed out that one way for systems engineers to begin meeting Lampson's challenge would be for them to make it easier to find out what is going on within the system. Lampson replied that some engineers take that idea too far: some Microsoft products allow too many ways to look at what's gone wrong. Lampson did manage to flush out at least one person who would defend our community's role in the development of the web. Noah Mendelsohn argued that we did all the hard work such as connectivity and streams, while Tim Berners-Lee only caught the social aspects. Lampson quipped that in a way, that makes our failure even worse.
Slides from this presentation are at http://www.research.microsoft.com/lampson/Slides/ComputerSystemsResearchAbstract.htm.