THVV Multics bio

Tom Van Vleck

In almost 15 years on Multics, I worked on many parts of the system, including system boot, login, administration and accounting, operations, BOS, system console management, documentation tools, tape, backup, transaction processing, error handling, development process, and the file system. I wrote many commands and subroutines and added features to many more, from mail and help to print and use.

I joined MIT Project MAC in 1965 to work on CTSS and moved on to Multics boot and system administration. In 1969, I went to MIT IPC to manage CP/67, CTSS, and Multics programming. I joined Honeywell Cambridge Information System Laboratory (CISL) in 1974, transferred to Honeywell Phoenix to manage Multics developers in 1978, moved back to CISL in 1980, and finally left Multics in 1981.

I am especially proud of my contribution to the Multics New Storage System (NSS), which replaced the system's disk organization to improve system scalability, capacity, and reliability. I coordinated the work of up to 25 colleagues, wrote major design documents, programmed some key pieces, and served as librarian and build coordinator. About 75% of the hardcore supervisor was modified by this project.

I also represented Multics on the Honeywell LISD Palyn report evaluation committee, and presented Multics in talks and conference papers.

When I left CISL in 1981, I was the second highest submitter of Multics Change Requests (MCRs). Steve Herbst was first; he specialized in bug fixes, and most of mine were feature introductions.

I was lucky to work with and learn from some of the smartest and kindest people in the business, on a system that had ambitious goals and time to accomplish many of them. When I think back about Multics, I remember the wonderful people first, then the good times we had, and then the neat things we built.

We used to speak of building things "the Multics way." To me this meant trying to solve the general problem as well as the immediate one; open discussion of every technical point; continuous evolution of our product and our process; and attention to consistency, elegance, and evolution. Doing it right rather than doing just enough. When the Multics hardware is obsolete and the code lost, I'll still prefer to develop software the Multics way.

Dick Gabriel wrote a lovely essay titled "Worse is Better," in which he contrasts the "MIT Approach" versus the "New Jersey Approach." These are intentional caricatures, but roughly contrast putting perfect design first, versus putting simple implementation first. Many mistaken articles about Multics have identified its approach as equivalent to Gabriel's "MIT approach." In fact, I think this is not true, and that the approach we took when building Multics is somewhere between Gabriel's poles. There's a moving-target problem here: the approach practiced at CISL in the 70s and 80s was not necessarily the same as used by Project MAC, GE, and Bell Labs in the 60s. Nevertheless, our focus on getting a system up as quickly as possible, with adequate performance, led us to postpone or eliminate unnecessary features ruthlessly. We often applied the "80-20" rule, trying to get 80% of the function accomplished with 20% of the code, leaving evolution towards 100% for later. We did spend time discussing what 100% of a feature was, and sometimes implemented first-draft versions that we learned from when implementing later versions. All the good parts of Multics were good because they improved on earlier versions. Corby and Charlie's paper on management of Multics captures some of this.

Programs I Wrote

All Multics software was a team effort, and my colleagues had substantial influence on things I did and vice versa. Here are some programs I began, or took over and made my own for a period of time. Others subsequently rewrote and greatly improved some of them, learning from my mistakes.