Seibel: How do you read code? Let’s say you’re going to learn a newlanguage and you find a program to read—how do you attack it?

Allen: Well, one example was one of my employees had built a parser. Thiswas later on for the PTRAN project. And I wanted to understand hismethods. It’s actually probably the best parser in the world—now it’s out inopen source, and it’s really an extraordinary parser that can do errorcorrection in flight.

I wanted to understand it, so I took it and read it. And I knew that PhilippeCharles, the man who had written it, was a beautiful programmer. The way Iwould approach understanding a new language or a new implementation ofsome very complex problem would be to take a program from somebodythat I knew was a great programmer, and read it.

Seibel: And how do you get into a piece of code like that? Do you tracethrough the execution? Or read from top to bottom and just build astructure in your mind? It’s a sort of tricky reading problem.

Allen: Well, it is a tricky reading problem, but I usually had some intuitionabout or learned what the structure of the solution was, and then would goin and start maybe in the middle and look for the kernel piece. And it was awonderful way to learn not only the algorithms that were used but how touse the language in an elegant way.

Seibel: Do you have any favorite debugging war stories?

Allen: There were a couple. I remember one from the MAD system. Themachine operator called me in the middle of the night because it wouldn’trun a program that had been submitted for running overnight. There was away in which we did automatic checksumming to ensure that the data wasright because the machines themselves didn’t have much error detection,and no error correction.

I couldn’t figure it out on the phone. It took a little while, but suddenly Irealized that the way I had built the checksumming piece of the system didnot handle a particular case. Even when the program was correct it couldn’tpass that barrier because of the way I had calculated the checksum. And Icalled the man back and there was a way of getting around it.

Then there was another one where—this one I remember because I wasvery pleased with myself—I had an employee on Stretch who preferred towork all night. He came in in the morning and he was a very intimidatingman—giant guy and a very serious fellow. And he threw a debug listingacross my desk—a dump of the program—a huge, thick thing. And hepointed to one particular bit in that dump, and he said, “Why is that bitset?” He had been worrying all night on it. And oddly enough, I knew why. Itwasn’t a bug but it was something that he didn’t know what it was there forand had been assuming that that was the cause of the error.

Seibel: So that was later; you said there was another project betweenMAD and the Stretch.

Allen: Yes. It was for a scientist here that was doing wiring diagrams for thehardware. It had to do with laying out wires on what passed for chips atthat time. It was a mathematical solution we were implementing and it had alot of constraints, of course, because of the size of the real estate. I wasworking as a programmer on that. There were two of us, maybe three—allwomen.

Seibel: And then it was on to the Stretch project, which was a big one.

Allen: From my experience with Fortran and knowing that compiler verywell, I got drafted from Research to go and work on the next big project atIBM—the Stretch machine. It started in 1955—it got the name Stretch in’56 I guess—and was going to be 100 times faster than anything else in theworld—an absolutely amazing machine.

It was well recognized that the compiler was going to be key to the successof the machine and that the biggest challenge to achieve that performancewas going to be access to memory and that the compiler played a big role inthat.

Seibel: Because dealing with the memory latency was going to be morecomplex than programmers writing assembly by hand were going to be ableto handle?

Allen: Yes. And because the memory-latency problem was being solved bya lot of concurrency in the hardware—very complex concurrency. And thememory organization itself was multiway-interleaved and it wasunpredictable what order data would be delivered to the computationalunit. Six accesses could be in flight at the same time. There were pipelines inthe computational unit itself and there was an ability for multipleinstructions to be in execution at the same time. And the most complicatedunit on the machine was a look-ahead unit, because they had preciseinterrupts as part of the architectural design, so not only did it have to keeptrack of all the concurrency going forward, but they had to back it out whenthere was an interrupt.

It was an extremely complicated machine and a wonderful one to program.The compiler had a very big challenge in order to take advantage of it. It wasa wonderfully challenging project.

So a bunch of us were drafted out of Research to come and work on thecompiler and the operating-system software itself. The compiler itself was asgrandiose as the machine. I ended up, because of my previous exposure tothe Fortran optimizer, involved with the optimizer for the Stretchmachine—the Stretch Harvest, as it turns out. The outlines of the compilerwere established by a different committee but there were four of us whowere given the charge of filling in the details, including the interfaces in thecompiler and what the specs were for that and taking charge of the differentpieces of it. I had the optimizer, and somebody else had the parser, theregister allocator, and the interface with the assembly program.

Seibel: How was the project structured in terms of the technical peopleworking on it?

Allen: Well, there were around three people who laid out the overall designof the compiler—we’re going to have a parser, we’re going to have this andthat, and then where it fit. And there was somebody above them—this was aproduct, so there were more layers of decision-making and management.

Then they needed to have project overseers for each of the bigcomponents. So they asked four of us, three of us being women, to getinvolved, to get together as a team and design the interfaces.

Seibel: And then were there other programmers working on the actualimplementation?

Allen: Yes. I had a group of 17, all doing programming.

Seibel: What was the relation between the design phase and the coding?You four got together and sorted out the interfaces between the parts. Didthat all happen before your 17 programmers started writing code, or didthe coding feed back into your design?

Allen: It was pretty much happening as we went. Our constraints were setby the people we reported to. And the heads of the different pieces, likemyself, reported to one person, George Grover, and he had worked outthe bigger picture technically. And a lot of it was driven by the constraintsof the customers. There was a lot of teamwork and a lot of flexibility at thetime, in part, because we were kind of inventing as we went. But under adeadline. So there was not as much management hierarchy, but just beingmore part of the team.

Seibel: Did the people below you ever write code that would then forcethe realization that some of the higher-up decisions about how the pieceswere going to fit together had to be revisited?

Allen: Yes, how this interface is not going to work. Keeping track of howthings were coming together was a part of it. We would meet as a team, thefour of us. But most of our time was spent on trying to build thecomponent that we were responsible for—there was a lot of freedom.

Software engineering came much later. There wasn’t software engineeringand there weren’t big processes set up yet. On a subsequent project, the360, run by Fred Brooks, which I wasn’t involved with, the software was ahuge crisis. The engineering on the 360 was doing pretty well around ’63.And some engineers moved over from building the machines—hardwareengineers—guys that just knew nothing about software—to run thesoftware because it was so out of hand. And it was really a mess.