That transition happened with my the next big cluster of work, which wasthe work that I did at Berkeley, mostly as an undergraduate, on ProjectGenie: the 940 timesharing system and on the QED text editor. And Iwrote an assembly-language debugger but I don’t remember much ofanything about it.

The piece that had the most system flavor to it was the operating system.It’s not fair to say that I wrote the whole operating system; I didn’t. But Iessentially wrote the whole kernel. This was done in assembly language.We’re talking about programs that are getting to be a little larger here,probably on the order of 10,000 lines of assembler. It had a processscheduler. It had virtual memory. It had a file system. In fact, it had severalfile systems.

There, there were more complex questions of data-structure design. Theone that I remember is there was an active process table. And there was aquestion as to how to design that and how the operating system shoulddecide when a process was runnable or not—that kind of thing. There werestructures for keeping track of the virtual memory system. But some issuesof interface started to emerge. Not within the operating system itself,because the operating system was so small that the kernel was designedessentially as a single piece, as a monolith.

But there were two important areas where issues of software interfacestarted to emerge. One of them was simply the interface between userprograms and the kernel. What should the system calls be? How should theparameters be laid out? I know that in the first few versions of the 940 TSS,the basic operations for reading and writing files were the equivalent of theUnix read and write calls, where you basically gave a base address and acount. Well, that was all very well and good, but a lot of the time thatwasn’t what you wanted. You basically wanted a stream interface. And inthose days, we didn’t have the concept that you could take an operating systemfacility and then wrap user-level code around it to give you somenicer interface in the way getc and putc get built on top of read and write.So what we actually did was in later versions of the operating system, weadded operating-system calls that were the equivalent of getc and putc.

The other place where issues of interface started to show up were—again,based on the MULTICS mode—from the beginning we had a strongdistinction between the kernel and what today we would call the shell. Thiswas early enough in the development of operating systems that we didn’trealize that you could, in fact, build a shell with essentially no specialprivileges. The shell was a user-mode program, but it had a lot of specialprivileges. But there were some issues about what facilities the kernel hadto give the shell—what things the shell should be able to do directly andwhat things it should have to make kernel calls for.

We saw interface-design choices just emerging from the task. That was thepoint in my career at which I dimly started to become aware that interfacesbetween entities really needed to be designed separately, that the interfacesbetween them were also an important design issue.

So responding to your question about whether the way I programmed inthe small changed as I started to work with larger systems, the answer is,yes. As I built larger and larger systems, I found that when sitting down towrite any piece of code, more and more the question I would ask myselffirst is, “OK, what’s the interface between this and everything around itgoing to look like? What gets passed in? What gets passed out? How muchof a task should be on which side of an interface?” Those kinds of questionsstarted to become a larger and larger part of what I was dealing with. Andthey did affect the way that I wrote individual smaller chunks of code, Ithink.

Seibel: And this was a natural consequence of working on biggersystems—eventually the systems get big enough that you just have to find someway to break them apart.

Deutsch: That’s right. In that sense I agree that software is fractal in thatdecomposition is an issue that happens at many different levels. I was goingto say I don’t think that the kinds of decomposition at bigger grains arequalitatively the same as the kinds of decomposition that happen at smallergrains. I’m not sure. When you’re doing decomposition at a smaller grainyou may not be thinking, for example, about resource allocation; whenyou’re doing decomposition at a larger grain you have to.

Seibel: Have you worked with people who, in your opinion, were verygood programmers, yet who could only work at a certain scale? Like theycould work well on problems up to a sort of certain size but beyond that,they just didn’t have the mentality for breaking systems apart and thinkingabout them that way?

Deutsch: I’ve worked with programmers who were very smart but whodidn’t have experience at larger-scale programming. And for Ghostscript, Idid have some pretty serious disagreements with two of the engineers whowere brought into the team as it was getting handed over to the companythat I started. Both very smart and hardworking guys, both experienced. Ithought they were very good programmers, good designers. But they werenot system thinkers. Not only were they not used to thinking in terms ofthe impact or ramifications of changes; they to some extent didn’t evenrealize that that was an essential question to ask. To me the distinction isbetween people who understand what the questions are that you have toask in doing larger-scale design and the people who for whatever reasondon’t see those questions as well.

Seibel: But you think those people—when they’re not trying to be thearchitect of a whole system—do good work?

Deutsch: Yeah. The two engineers that I’m thinking of both did really greatwork for the company. One of them was working on something that waslarge and rather thankless but important commercially. And the other oneredid some substantial chunks of my graphics code and his code producesbetter-looking results. So these are good, smart, experienced guys. Theyjust don’t kind of see that part of the picture—at least that’s my take on it.

Seibel: Are there particular skills that you feel made you a goodprogrammer?

Deutsch: I’m going to give you a very new-age answer here. I’m not a newagekind of guy generally speaking, although I went through my period ofreally long hair. When I was at what I would consider the peak of myabilities, I had extremely trustworthy intuition. I would do things and theywould just turn out right. Some of that was luck. Some of it, I’m sure, wasexperience that had simply gotten internalized so far down that I didn’t haveconscious access to the process. But I think I just had a knack for it. I knowthat’s not a very satisfying answer but I truly believe that some of whatmade me good at what I did was something that was just there.

Seibel: In your days as a precocious teenager hanging out at MIT, did youhave had a chance to observe, “Wow, this guy’s really smart but he doesn’tknow how to do this thing that I know how to do.”?

Deutsch: No, I didn’t. Well, OK, I do remember when I started rewritingthe text editor on Dennis’s PDP-1; I must have been 15 or 16. The originalcode had been written by one or two of the guys from the Tech ModelRailroad Club group. Those were smart guys. And I looked at the code andI thought a lot of it was awful.

I would not say it was a difference between me and the people I wasworking around. It was a difference between the way I thought code shouldbe and the code that I saw in front of me. I would hesitate to generalize thatinto a statement about the people.

I’ve always been really comfortable in what I would call the symbolic world,the world of symbols. Symbols and their patterns have always just been thestuff I eat for lunch. And for a lot of people that’s not the case. I see it evenwith my partner. We’re both musicians. We’re both composers. We’reboth vocal performers. But I come at music primarily from a symbolic pointof view. I do a lot of my composition just with a pencil and a pad of paper.The notes are in there but I’m not picking them out on the piano. I hearthem and I have a plan.