After the 360 got shipped one of the people—I don’t know that he’d beeninvolved with the 360—wrote a letter to the higher-ups in IBM proposing asoftware-engineering discipline called Cleanroom. He made statement that if youfollowed all these set of processes he was laying out, you could write perfectprograms. And because of what management had been through—this is myversion—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 overto the Cleanroom processes—a whole set of processes. One of the thingswas that there would be somebody that would set objectives and therewould be another group that did the design. And the designers wouldspecify the design to the detail that the programmers could write to thedesigns. And these groups were not interactive—you just did this cleanlyenough, and perfect software came out.

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

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

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

Allen: It was absolutely necessary, but it was so painful for the softwarepeople to have these guys—all guys—move in, knowing nothing aboutsoftware, 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 thisnext 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 Cleanroomprocess, the waterfall process, came in through management with a verystrong 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 thathe 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 structurewere appalled at the statements at the time. But sometimes one has tomake bold claims in order to sell something.

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

Allen: Oh, yes. And found it frustrating because in its early stages, adesigner and the programmer could not interact. One of the problemswas—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 tookmonths and months or years. And the environment changed and therequirements changed. And the customers really did have the say in whatthey wanted in the end.

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

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

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

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

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

Seibel: Even with flowcharting, there are formal flowcharts produced asdocumentation and then there are the flowcharts you draw on a blackboardto 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 ofthings 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 orwhatever period of time.

Seibel: So the big project you led was the PTRAN compiler project, whichwas when you first started working on explicit concurrency, as opposed tothe implicit concurrency in the CPU pipelines and so forth. When youstarted 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. Thegreat work that initiated it from a real pragmatic point of view was at Illinoisstarting in ’69 and ’70.

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

Allen: That’s right, that’s where we started from. What I wanted to do wasto do the same thing we’d done for optimization: The user writes asequential code in the language in a way that’s natural for the application andthen have the compiler do the optimization and mapping it to the machineand 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 ofthe hardware’s parallel components.

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

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

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

Seibel: On the PTRAN project, you were leading a team. Were you stillcoding 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 couldbe implemented in any reasonable time. I mean, it was a very goodalgorithm, but I didn’t see an implementation that was bounded in time andspace in some real way. So I had that challenge out there. I had to see thatcode. I needed it. It had to be implemented. It couldn’t be just a paper—avery nice paper, a famous paper—that shows graphs and complexitybounds.

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