After the 360 got shipped one of the people—I don’t know that he’d been involved with the 360—wrote a letter to the higher-ups in IBM proposing a software-engineering discipline called Cleanroom. He made statement that if you followed all these set of processes he was laying out, you could write perfect programs. And because of what management had been through—this is my version—they bought the whole thing.

Seibel: Because the 360 project had been so painful?

Allen: That’s right. So IBM product development moved very strongly over to the Cleanroom processes—a whole set of processes. One of the things was that there would be somebody that would set objectives and there would be another group that did the design. And the designers would specify the design to the detail that the programmers could write to the designs. And these groups were not interactive—you just did this cleanly enough, and perfect software came out.

Seibel: On the 360 project, Brooks was in charge of both software and hardware, right?

Allen: Yes, I think he had the whole thing. But he replaced some of the software heads with people with hardware experience. And it was really the right thing to do because the hardware people already had a wonderful discipline around building hardware—the chip design and the testing process and all of that. And that was an older and much more rigorous ways of expressing designs. We software people were just making it up.

Seibel: So you feel that, at least on that project, that they brought something to the software-development process that saved the project?

Allen: It was absolutely necessary, but it was so painful for the software people to have these guys—all guys—move in, knowing nothing about software, and just impose design reviews, design specs, all of this stuff.

Seibel: So it did help save that project. Did that embolden folks to take this next step to the Cleanroom process that was sort of a step too far?

Allen: Yeah, I think it did. That was the sequence. And the Cleanroom process, the waterfall process, came in through management with a very strong advocate for it.

Seibel: And that advocate was from the hardware side?

Allen: No, the advocate was from the software side. But I don’t think that he had been part of the 360 project, in the depths of trying to rescue that. But some of us who already had some experience with software structure were appalled at the statements at the time. But sometimes one has to make bold claims in order to sell something.

Seibel: Did you ever work on a project where that kind of process was used?

Allen: Oh, yes. And found it frustrating because in its early stages, a designer and the programmer could not interact. One of the problems was—probably still is—that the life cycle of a piece of software is very long. And at that time, if you were building a big piece of software, it took months and months or years. And the environment changed and the requirements changed. And the customers really did have the say in what they wanted in the end.

Seibel: Would you then push changes all the way down through the process? Or did people start short-circuiting the process, going directly to the programmers and saying, “All right, we figured out the customer needs X”?

Allen: Yeah. One could never really write specs that were going to be adequate and useful at a detail level over the years of the life cycle. That was a problem. And now we have another process, of course—just do it and throw it away, kind of.

Seibel: Well, it was Brooks, in his famous book, who said, “Build one to throw away because you’re going to.”

Allen: Yes. And in fact, that is true—I very much believe that. But lots of times, that has led, in my opinion, to not thinking at all before you start building.

I always like to have a picture—a model. Often a flowchart and some specification about the interfaces. We were heavy users, of course, of flowcharts at that time because one didn’t get access to the machine that often and that was a very nice model for thinking through how parts of the system would interact, what would be done, and specifying what would be done where, and the functionality of the various components. I don’t know what the analog of that is now.

Seibel: Even with flowcharting, there are formal flowcharts produced as documentation and then there are the flowcharts you draw on a blackboard to try and understand something. Was it more of the former or the latter?

Allen: In some cases, it would be formal flowcharts. Often in the kernels of things there were some very complex pieces and one would do that. Otherwise, it was just informal and a way of working at solving a problem. Blackboards would be covered and become the record for the month or whatever period of time.

Seibel: So the big project you led was the PTRAN compiler project, which was when you first started working on explicit concurrency, as opposed to the implicit concurrency in the CPU pipelines and so forth. When you started that, that was a new thing, both for you and for IBM.

Allen: It was new for IBM, but we were very, very late coming into it. The great work that initiated it from a real pragmatic point of view was at Illinois starting in ’69 and ’70.

Seibel: And what language did the PTRAN compiler compile? Was it straight Fortran with no added constructs for parallelism?

Allen: That’s right, that’s where we started from. What I wanted to do was to do the same thing we’d done for optimization: The user writes a sequential code in the language in a way that’s natural for the application and then have the compiler do the optimization and mapping it to the machine and taking advantage of concurrency.

In PTRAN, the idea was still to take the “dusty decks,” as we called them, referring to an existing code base, and to automatically take advantage of the hardware’s parallel components.

Seibel: So, essentially, that was targeting what today we would think of as symmetric multiprocessors?

Allen: Yeah, could be. There are many, many models of parallelism, which is one of the difficulties. I think that that can be greatly simplified. But multicore is one of the things that really are particularly interesting, for me at least. But there are many models of parallelism.

We actually built it from existing work, particularly Dave Kuck’s. Some work from NYU. We hired a group of newly minted PhDs from these places that already had built up a lot of expertise. We had a quite a lot of significant results, both on the practical and on the theoretical side—we worked on both at the same time. I’m a very strong believer that one wants to be able to take the practice into identifiable algorithms, and theory, and ways of thinking about how to solve the problems and also to take the algorithms into practice to see how really valuable they are, and how they apply. I think our field is best done when it works on both sides on the same projects.

Seibel: On the PTRAN project, you were leading a team. Were you still coding at all by then?

Allen: I wasn’t doing the coding, but I was very close to it. As an example, when the Static Single Assignment work was done, I didn’t see how it could be implemented in any reasonable time. I mean, it was a very good algorithm, but I didn’t see an implementation that was bounded in time and space in some real way. So I had that challenge out there. I had to see that code. I needed it. It had to be implemented. It couldn’t be just a paper—a very nice paper, a famous paper—that shows graphs and complexity bounds.

If we can’t implement it in a real system, that challenge would still be out there. It wasn’t going to be as useful as I wanted it to be. Finally, one of my people had an encoding. And I walked through that, every piece of that code, and looked at the data structures that were used. And it was astounding. I said, “This is it. It works.”