The creation of the Unix operating system was a collaborative effort of many mathematicians and theorists, and much of the success of the project was due to the people involved and the environment in which the system was written. Unlike most businesses, the workplace at Bell Labs was relaxed, and specific tasks were not assigned to individuals. According to Kernighan, who worked with the same group at Bell Labs before joining the Unix project, each person worked on projects of their choice:
It's interesting, I had so much fun here in '67 and '68-just, you know, the people. It was just such a good collection of people, and I've enjoyed it. I never interviewed anyplace else; I never even thought of any other place. I simply said I'd like to work here. And Sam Morgan, in his wisdom, said, "We don't want any Ph.D. dropouts, so you have to get your degree finished. But, other than that, sure, we'd love to have you." That was it, and I came early in '69 and the charter, or my instructions, were-as they are for everyone else-non-existent. Do what you want. The hope is that the combination of people around you, doing things that are interesting-and perhaps ultimately relevant, but not instantaneously relevant, I don't even know-but the combination of people around you doing interesting things, and getting their jollies, I think, from having their interesting things affect other people, means that there's this sort of gentle gravitational pull towards doing the same kind of thing yourself. It's clear the reward mechanism ultimately favors those people who have an impact on the local community, impact on the Bell Labs community, impact on AT&T, impact on the scientific community, in some combination.
Likewise, Bob Morris felt that the researchers' freedom was essential and probably would not have been possible at any other point in time.
...General attitude. People contributing system software and that crucial, there were not working toward externally separate departments. We were not bidding on some Goddamn government project. Which meant somebody who didn't know anything had set out a lot of ways of how the system should operate...We had almost total freedom in that, and we were able to, and it's a luxury. I mean no one could do that kind of stuff with Unix now. Couldn't possibly. Not with AT&T Unix. Not with any Unix. You just couldn't possibly laugh and see something go so wrong with a program. See that it was wrong. Go in, find the place when the change needed to be made and install the result. Hey, that was perfectly reasonable in 1974. By 1978, it was absolutely out of the question.
From the management side, this idea of freedom and the importance of creating personal projects was reflected in Morgan's hiring practices. Morgan relates,
...We have the philosophy that you hire bright people, you expose them to interesting problem areas, and you keep an eye on what they are doing and in particular on their interactions with other people. You attempt to give them guidance only in a very general sort of way. Often times this guidance is simply a lot of enthusiasm for something that they are working on. An environment like that is self perpetuating, so long as you keep your hiring standards up and your management keeps its eyes open.
Another unique feature of the Unix project was that the mangers were technically trained people with similar qualifications to those developing the tools. Morgan says,
...The management around, around Bell Labs all are, at least around the research area, all came up through the technical route. And people don't get promoted to management in the research area here unless they have a good track record. You may find a few folk who disagree with that. But my view is that our department heads and directors and executive directors were once technical hot shots. Sometimes that back fires, because you get a technical hot shot who has no people skills. But that is a different story. Your technical people, your managers were once technical hot shots and they were imbued with this general philosophy of how you conduct, how you manage research at this kind of place. And good things come out of this...philosophy of research management...I didn't create this, to some extent I keep it going
Morgan felt there was a delicate balance between giving people complete freedom and assigning tasks. Also, he only gave explicit approval to certain projects when he felt the group was ready ("selective enthusiasm"), for instance when Thompson's group asked for a computer. In Morgan's words,
You can't make it happen. You hire bright people, provide them with a stimulating environment. And you do selective pruning and encouragement of what they undertake. But you don't do this with too short a time constant. As I said, the first time that Thompson and company asked for a computer, they asked for a DEC PDP-10 and they were told no on that. It was simply too big and you are not going to do operating system research for a big computer just after Multics has been turned off. The second time they asked, they wanted a PDP-11/20 and I said, "I am not convinced yet, I want to see more of what you say you are going to do with your text processing system." So I didn't stomp on them, but neither did I sign their order, and they found somebody else, another director to sign the order, and the third time they came around they wanted an 11/45 and by that time they had a perfectly plausible and defensible story. So they got selective enthusiasm used on them but not too violently or with too short of a time scale. If it is going to be good it will prove itself.
Similarly, Kernighan felt that there was no direct management and that the group's success was due to both coincidence and the people involved. He explains,
I don't think it was directed, or least if it was directed, it was done in an incredibly deft and unobtrusive way. Maybe management will tell you that that's worse... .If that is true then it is to their eternal credit. Now, I think, in a sense-I mean, Doug was management of at least some part of that. I guess Ken technically was in Doug's department, and Doug is superb [with] that kind of stuff. Insofar as he manages it, he does by superlative constructive criticism at the right time, and by going out and trying your stuff and finding out where it works and where it doesn't work, and then telling you what was good about it and what didn't work. To a lesser degree, I suspect that, in some sense, we all do that. I don't think that this was done by any direct management, so we can dispose of that part.
Part of it is a confluence of really good people with reasonably good taste. Particularly Ken and Dennis, who, as far as I can tell, genuinely have truly deep insight, and at the same time, good taste, and at the same time, essentially very close to parallel taste, so that they don't get going in opposite directions. Part of it is happy coincidence, that technology had gotten just about the right point where you could get hardware-a machine to work on-where you didn't have to, in some sense, be beholden to other people. You didn't have to use that machine their way because they paid for it, or something like that; that you could have something that's sort of your own, so you could furnish your computing world the way you wanted it, the way you are comfortable with it.
Bob Morris also commented on Doug McIlroy's role in the project, both on the managerial and technical levels. Morris narrates,
Doug was a manager and he had a supervisory responsibility for the whole thing anyway...He was a department head and I think it was being done by people in his department. There may well be exceptions but, most of them certainly were in his department. So, at the early stage, he simply watched this happen and thought it was a good idea, supported it, and helped in an administrative way to make it happen. Perhaps a couple of years later, he was right along in there pushing along with the rest of them. On the technical level. That's why in this stage I include him. I don't mean Doug as a manager, as a department head. But, as a technical might, he was in there by 1973 thereabouts.
At the same time, he felt that there was no particular leadership during the project, and stressed the importance of doing things yourself. Morris remarks,
It was [more cooperative]. I don't think there was any time when there was any notion of anybody adopting on leadership. If Ken asked somebody to do something, the answer would be, "Go suck a grapefruit"...Oh, no matter who he asked. Or if someone in the group had been asked to do something, "Do it yourself." There was no leadership that I detected for being in, was community.
In addition, there was a strong sense of responsibility for the quality of the work, resulting in projects supported by theory. According to Weinberger,
...there's definitely been a tendency is, if you don't know how to do it right, just don't bother in the Unix development. And I think that's one of the things that...leads one to choose things that are backed by theory.
Because I have this feeling I make mistakes, everybody makes mistakes, I also have this feeling that you never want to have to touch the programs. So it's important to do it right early and that it [will] always be okay.... It's not just a problem of the minute, although one writes a lot of code that's got to do the problem of the minute. It's got to fill the niche permanently, which is completely unrealistic but it's certainly an attitude. And I think that matches this other. If it's just going to be a slipshod temporary hacked up way of doing it it's just not going to work long enough. And you're going to just have to come back and do it again and it's just too much like work. Not that reality actually matches this in any way but I think that's the attitude. I think that makes it easier to pick up that ethos.
Although there was a push towards excellent quality of work, Weinberger asserts,
It's clear that the most powerful pieces of it have that property [of being theory-driven] and that many of the pieces, even where there's no clear theoretical piece behind them, have sort of... the next best cousin in programming language, designer stuff like that... .Unix is famous for this theory that it's best to do 80% because the last 20% is way too hard. But if there were a big piece you could chop off, then you did it. And that's why you get general regular expressions instead of some other version...I think regular expressions is clearly the...single thing that distinguishes the Unix way from other ways, the MS DOS way and many others. Yes, I think the compromises that are made are made somewhere else. Not made in these places where there are strong algorithms.
Lorinda Cherry felt that the theoretical foundation for the work led to an attitude of discipline. Nothing was included unless it was essential and people had to justify what they were doing, to some extent. Cherry comments,
There's certainly some discipline in what's allowed to hang around and what isn't. One can watch that in whatever manual is produced and Doug starts throwing programs or people start, 'Rather than document this file, we're going to remove it. It's not really necessary, there's another way to do it.'
As previously discussed, this was also a sense a sense of ownership, in that the last person to touch a program owned it. These two factors, discipline and ownership, were unique to this Unix project, according to Cherry. She compares it to the Berkeley Unix system, suggesting that the variations are possibly due to the differences between environments:
If you look at the Berkeley Unix system and some of the commands that are similar, the same in Berkeley as what we have here but you look at the Berkeley manual they've added 85 flags to the
catcommand or something. It was a very simple elegant thing that did a very simple job. I guess we've always had the attitude that it has to be really useful to be worthwhile putting in. Maybe just 'cause it was a smaller group than at Berkeley or maybe people in Berkeley, everybody needs to find a niche so they've got to put a flag on something, I don't know what the environment is there. But I think it was here to prevent featurism. I think that's the difference between the two systems. And I think that undoubtedly has to do with the university environment where everybody has to do something as opposed to the environment where in some sense everybody had to justify what it is they were doing to your cause. And there is also some hesitancy 'cause if you touched it you owned it, you thought hard about whether you needed to add that flag or whether there was some other way around it. Whether there was some program. You said ‘I'll find some other way to do this 'cause I don't want to own this program.’
At the same time, however, people were both willing and expected to help others with their programs in any way possible. One example of this responsiveness was the previously mentioned account of dc, told by Bob Morris. As shown from this example, collaboration played an integral role in the success of the project. The group discussed problems they were having, and often worked together to solve problems. A perfect example of this is AWK, a text processing language developed by Al Aho, Peter Weinberger, and Brian Kernighan. As the name implies, it was certainly not a singular effort.
According to McIlroy, the trend towards working together grew stronger with the introduction of pipes. One aspect of this approach that made their work more difficult was that they had to be very careful that all the parts would work together; when many small pieces are put together to form a finished project, the interaction between the pieces can often lead to mistakes. It is because of the internal efficacy of the individual pieces that the project as a whole was a success. McIlroy says,
This is the Unix philosophy. Write programs that do one thing and do it well. Write programs to work together. Write programs that handle text streams because, that is a universal interface. All of those ideas, which add up to the tool approach, might have been there in some unformed way prior to pipes. But they really came in afterwards.
In Morgan's opinion, the management encouraged this collaboration but sometimes had to help organize the partnership. Morgan observes,
We do encourage people to be enterprising, that if they want something done, or if they want somebody to cooperate with them...You will occasionally get someone with feels that he would like to have somebody working with him and this won't happen until somebody's boss says, ‘You two guys collaborate.’ One does not tell researchers to collaborate with each other. You find, you find common interests in somebody and then the collaboration occurs. So if somebody came to me and said, ‘You tell somebody to, you tell such and so to work with me.’ You make your own contacts. So folks...are encouraged to be entrepreneurial in the sense that they make contacts and they get collaborations going.
The cooperative efforts were facilitated by the close working environment. The attic had a lot to do with that, but the success was also due to the people working in the attic. Morgan remembers the group as tight-knit, spending time with each other even when they were not working. In his words,
From about 1970 to about 1976 or 1977 we had about two dozen people, twenty four people in the whole group. We were essentially not hiring anybody, we were in one of our chronic hiring freezes and we just had a small group of good people who generally ate lunch together, and who were quite willing to argue with each other and to discuss and to use the techniques they knew about to put together things that they thought were interesting. It was a lot of work in text processing at that time. There was a lot of work in practical operating system development. There was a lot of work in theoretical computer science, compiler theory and algorithms. It was done essentially by a handful of people. But they were people who did a lot of talking to each other and a lot of shouting and who essentially collaborated. And that is the way that research is supposed to be done.
This led to what Aho called "Darwinism in Unix." The programming languages were tested by users so that they would best suit the users' needs. Aho says,
Well, you [Mahoney] talked about Unix being a spirit. The one way that I view it is that there's a great deal of Darwinism in Unix. If one looked at how certain commands and languages came into being, it was because someone had an idea. Say like Kernighan and Cherry for this language for typesetting equations. They got a rudimentary form of the language processor to be up and running, and then they let their friends use it. Then the language evolved on the basis of usage patterns. That, as users gained more experience with the language, they would be able to say, ‘I'd like to have these additional features.’ Or, ‘These are some awkwardnesses in the language.’ So there was a Darwinistic evolution of the language, and, in fact, of the Unix system itself. That it is satisfied a certain user's needs, and there was enough time to refine the system so that it satisfied those needs...I thought, quite efficiently and quite elegantly. There is this "European approach," if you want to use that term, or this more dogmatic approach to language design, where you have some august committee that meets for a period of several years to come up with a language specification. They...write a document. Compiler writers work off that document for several years to produce a compiler, only to discover that there may be some infelicities in the language design. And, the process is much more cumbersome. Natural languages evolve, and I think, ‘Why shouldn't programming languages?’
Lorinda Cherry also described the importance of a natural programming language, specifically in reference to eqn:
...the graphics is easy. The hard part is getting a language that you can teach to a math typist that will just flow off her fingertips to complicated graphics. I think the language part of that was what was neat about it. It's still what's neat about it.
Morris also described the same necessity for an intuitive math program, also in reference to eqn:
...the damn thing ought to work and it ought to work in obvious ways and I didn't have a manual. Wasn't going to get one and never intended to look at one. [Brian Kernighan's] view was completely supportive of that...his view was if I used common sense and tried to create some construct, and I wrote integral from A to B of X that it should damn well produce a nice integral sign and an A at the bottom of it and a B at the top of it and an integrand and do all that without a lot of messing around and if it didn't recognize common sense ways that ordinary people say this is mathematical text so ordinary people who were writing that mathematical text, then it ought to be changed. And that's the way it stayed. I'm still a user of eqn, and I still never seen a manual with eqn. That's one of the credible ones. Because there are an awful lot of possible differences. I mean looking at competing packages of that sort damn near unusable, because you have to learn so many rules to operate them that by the time you learn half of the rules, you're already bored with the whole thing.
Morris conveyed this to Condon early on, and Condon expressed a similar feeling, describing it as "cognitive engineering". He spoke of going to Bob Morris and asking
‘How do you understand what these commands do? The manual pages aren't all that clear.’ [Morris] would say, ‘What do you think is the reasonable thing to do?’ Try some experiments with it and find out. I think that was a very interesting clue. At least his philosophy and some of the other people's philosophy, of Dennis's also, of how system commands should work. It should work in a way that is easy to understand. It shouldn't be a complex function which is all hidden in a bunch of rules. I think the concept of cognitive engineering...is that people form a model. You present them with some instruments, tools, like a faucet, electric stove or something like that and demonstrate how it works. They then form in their heads a model that shows how it works inside to help them remember how to use it in the future. It may be a totally erroneous model of what is going on inside the black box. What in fact is going on inside, I think Bob Morris [told] me, I know he felt this way, is that the black box itself should be simple enough. Such as when you form a model of what is going on in the black box that's in fact is going on in the black box. [Don't] write a program to try and outwit and double guess what they're going to want to do. You should make it such that it is clear about what it does.
This idea of clarity characterizes of the Unix philosophy. Unix was created in a environment of bright, motivated people from various backgrounds. They were given the freedom to invent their own projects and the system developed as a combination of inputs from a variety of people. There was no a organized structure, and tools were written as they were needed. Much of the work had a strong theoretical basis resulting in disciplined programming. Collaboration was also key to success, and this was enhanced by the close working environment. The researchers all worked together in the attic, and then continued their discussions outside working hours. They strove for intuitive and efficient programs, qualities that perhaps could not be replicated if the project were to take place under other conditions.