Peter Seibel - Coders at Work - Reflections on the craft of programming

But we have to be willing to try and take advantage of that, but also take advantage of the integration of systems and the fact that data’s coming from everywhere. It’s no longer encapsulated with the program, the code. We’re seeing now, I think, vast amounts of data, which is accessible. And it’s numeric data as well as the informational kinds of data, and will be stored all over the globe, especially if you’re working in some of the bioinformatics kind of stuff. And we have to be able to create a platform, probably composed of a lot of parts, which is going to enable those things to come together—computational capability that is probably quite different than we have now. And we also need to, sooner or later, address usability and integrity of these systems.

Seibel:Usability from the point of the programmer, or usability for the end users of these systems?

Allen:Of the end users of these systems. It’s a resource, a giant resource. And the integrity of the correctness of the systems. I worked on project for the NSA on risk management, quite a few years ago, and it suddenly dawned on me that we often, in high-performance computing, do not need to compute to the accuracy that we have. We do not need all the data to be able to make progress on a solution. And so there’s some nice work going on in the data side, I think, with accommodating good enough answers. I see these multicores—they’re a wonderful opportunity—to go back and to take another look at lots of things.

Seibel:Do you think of yourself as a scientist, an engineer, an artist, or a craftsman?

Allen:I think of myself as a computer scientist. I was involved in my corner of the field in helping it develop. And those were interesting times—the emergence of computer science—because there was a lot of question about, “Is this a science? Anything that has to have science in its name isn’t a science.” And it was certainly unclear to me what it meant.

But compilers were a very old field—older than operating systems. Some day want I to really look it up. The word compiler comes actually from the embedding of little snippets of instructions to execute. Like an add would be spelled out in very primitive terms for the machine. If you want to do an add, then it would go to its library that defined that and expand it.

But assemblers were also using symbolics. I’m not sure this is accurate, but I used to believe that the first early use of symbolics for names of variables came from a man named Nat Rochester, on a very early IBM machine, the 701 around 1951. He was in charge of testing it and they wrote programs to test the machine. In the process of doing that, they introduced symbolic variables. Now, I’ve seen some other things since that make me believe that there were earlier ways of representing information symbolically. It emerged in the early ’50s, I think, or maybe even in the ’40s. One would have to go back and see exactly how things were expressed in the ENIAC, for one thing.

Seibel:So somewhere along the line, you realized you had become a computer scientist, developing theories about compiler optimization and so forth. But you started out as a programmer, hired to write code. By the time of the PTRAN project you were managing a team of people who were actually writing the software. Why did you make that switch?

Allen:Well, probably two reasons—one, I wasn’t a very good programmer. I tended to make quite a few mistakes—unlike the conventional wisdom at the time that said that women make good programmers because they pay attention to details. I didn’t fit that category. So I tended to be kind of disinterested in getting all the details right and I was much more interested in the way systems work.

My interest in mathematics was very abstract. If I had had enough money to go on to get a PhD, I would have become a geometer. I loved the rigor of that process. That’s what I really most enjoy, puzzling through systems—puzzling through the engineering kinds of things without necessarily knowing the details of what one would need to know to be an engineer, which is quite a different area.

Seibel:The way you contributed technically to the PTRAN project, it sounds like you had the big architectural picture of how the whole thing was going to work and could point out the bits that it wasn’t clear how they were going to work.

Allen:Right.

Seibel:Do you think that ability was something that you had early on, or did that develop over time?

Allen:I think it came partially out of growing up on a farm. If one looks at a lot of the interesting engineering things that happened in our field—in this era or a little earlier—an awful lot of them come from farm kids. I stumbled on this from some of the people that I worked with in the National Academy of Engineering—a whole bunch of these older men came from Midwestern farms. And they got very involved with designing rockets and other very engineering and systemy and hands-on kinds of things. I think that being involved with farms and nature, I had a great interest in, how does one fix things and how do things work?

Seibel:And a farm is a big system of inputs and outputs.

Allen:Right. And since it’s very close to nature, it has its own cycles, its own system that you can do nothing about. So one finds a place in it, and it’s a very comfortable one.

Seibel:You mentioned earlier that when you were working on the Stretch compiler, that three of the four people leading the compiler effort were women. Can you talk about how that came about?

Allen:This was in ’59, something like that. Women were playing a big role at that time as programmers. And IBM has always been a great, great company on that. I saw some history recently, that IBM’s diversity policies go back to 1899, just consistently, all through these periods when there wasn’t much attention being paid to that—very explicit policies.

Seibel:Do you think the number of women on that project was due to explicit management policies—that they were saying IBM should hire more women?

Allen:I don’t think they said, “We must hire more women.” They just hired whoever was qualified, and it wasn’t just women. These were really hard times for African-Americans, and IBM really stepped out. One story that’s not very well known is there was segregated housing in Poughkeepsie at that time, regarding blacks, and IBM got it changed.

Seibel:You told a story in an interview once about one time you arrived at a conference. And they looked at you and said, “Fran Allen?”

Allen:“You’re a woman.”

Seibel:“We have you rooming with Gene Amdahl.”

Allen:Oh, yes, that one. This was an IBM conference, when we were moving the System Y project that was going on here to the West Coast into product development and had renamed it ACS. We had a big conference at the Harriman Estate across the river. It was all, with one or two exceptions, IBM people. There was a person from the West Coast who was charged with organizing it and he didn’t know any of us. He’d done it alphabetically.

Seibel:So they sorted you out and found you a room by yourself?

Allen:Yeah, a maid’s room up in the garret.

Seibel:Did you publish papers under Fran or Frances?

Allen:F.E. Allen. And I don’t recall why I did that. I think it was fairly common, at the time at least, to just use first initials.

Seibel:You also mentioned before that when you started, people thought women would be good programmers because women were thought to be detail-oriented. These days the conventional wisdom is that it’s men who have a bizarre ability to focus on things, usually to the detriment of everything else, and that’s why most programmers are men.