Seibel: So you were looking at all of the pieces that were going to go intothe whole system?

Allen: Yes, yes, yes.

Seibel: You also were managing all these people? Or were you a technicalarchitect with someone else managing the group?

Allen: No, I was the research manager for the group. There were about 10or 12 core people and we divided the work up so that each person reallyhad ownership of a piece of it.

Seibel: People have been debating at least since Gerald Weinberg’s bookThe Psychology of Computer Programming whether it’s better for people to“own” code, so they take responsibility for it, or to have people work morecollaboratively so you avoid having silos that only one person understands.It sounds like you thought dividing up the ownership was the way to go?

Allen: We worked collaboratively, but the collaboration was about thestate of the system, of the implementation. And some people were verygood at the implementation, and so they’d own a piece—some piece of theoptimizer or the intra-procedural analysis was definitely one or two people.But also, there were a number of people that were doing a lot of the theorywork, or the abstract work of writing the papers, and writing a lot of thepapers and algorithms. And it was the bringing together of those two specialparts that I think really made the group so strong.

This was a period of a lot of work going on in the analysis andtransformations for parallelism. So what I tried to do was, for each of thepeople that were doing theory to get them to write some code, express itin code as a part of the system. And the people who were just doing theother part, well I’d try to get them to write things up so they were moregenerally available.

Seibel: A lot of programmers will do anything to avoid becoming amanager. Was managing something that you also enjoyed?

Allen: Well, Research in the earlier times did not distinguish—doingmanagement was not a promotion, not a salary raise. It was just somebodyhad to manage this piece of work, and “OK, don’t you want to do it?” Or,“You’re the obvious one to manage this piece of work.” And it wastechnical management; there wasn’t much people management involved. Butin Research people are RSMs, Research Staff Members, the day they enter,and for the rest of their career mostly. All my colleagues, that’s what weare. So one moved in and out of management without any stigma attached.

Seibel: So presumably the people who got chosen to manage were theones who were actually good at it. How did you pick up those skills?

Allen: Well, I was sent to management school. Everybody was, back when Iwas first appointed. But I think it goes back to when I grew up on the farm. Iwas the oldest of six kids and there were five of us in a row, so my parentswere pretty overwhelmed. So it was a natural role for me in some ways.

Seibel: One of the difficulties of the kind of technical management that youwere doing is finding the balance between having your own technicalopinions about how stuff should be done and giving people room to puttheir own ideas in.

Allen: I think I had some hard lessons on the Stretch project. I remembersome of the people on the project came in and said to me one day that weought to be using list and hash functions. Well, we knew about list programsbut hashing was new. So a couple of my people came and said they wantedto use hashing for the symbol table. And I said, “No, we can’t do that. Wedon’t know how to do that.” Yadda, yadda, yadda. The next Monday I camein and they had done it. They had torn down the system and rebuilt it withhashing. It worked, and it was much faster. So that was a big lesson to me. Ishould be much more open to some brand-new ideas.

Seibel: So sometimes—maybe even often—your people actually knowwhat they’re talking about and you shouldn’t interfere too much becauseyou might stomp out a good idea. It’s trickier when you’re really right andtheir idea really is a little bit flawed but you don’t want to beat up on themtoo much.

Allen: There was some of that. It was often where somebody came in witha knowledge of some area and wanted to apply that knowledge to anongoing piece of project without having been embedded in the project longenough to know, and often up against a deadline.

I ran into it big time doing some subcontracting work. I had a group ofpeople that was doing wonderful work building an optimizer based on thework we’ve done here for PL/I, a big, different language. But one of thepeople working for the subcontractor had just discovered object-orientedprogramming and decided that he would apply it to the extreme. And Icouldn’t stop him, even though I was the contract overseer, and the projectwas destroyed. Ultimately, what did it was PL/I has lots of pointers andtracing a pointer is done all the time, and it took 11 instructions to trace thevalue, to find the value of one pointer consistently.

Seibel: You mean in the generated code.

Allen: In the generated code and in the compiler itself because it wasbootstrapping the compiler. Every time you made a step you had to checkthat the thing’s valid. And you were checking, and rechecking, andrechecking. It still happens today. Some of these lessons we haven’t learnedwell. And I guess I was not dealing with it very well, because I should havejust pointed out what the cost of applying object-oriented technology in thatkind of situation. It was just hopelessly slow, so the whole thing gotcanceled.

Seibel: When were you most directly building a product for IBM, withproduction deadlines that had to be met?

Allen: Certainly, the Stretch project was that way. And I’ve worked inproduct development two or three times, and been in the situation whereone has week-by-week code reviews right up against deadlines. I have a lotof respect for those processes and how important they are for the endresult and for the team that’s doing it. It can be very painful to sit thereevery Friday and do code reads with people explaining why they’re doingwhat they’re doing and finding other people’s errors.

Seibel: Painful, but worthwhile?

Allen: Absolutely worthwhile. On the PTRAN project, towards the endwhen we were shipping a piece of it to the products, a half a day wasdevoted to explaining errors in our code, their code, whatever it was, everyweek. That went on for ten months, I think. Devoted Friday afternoon to it.

Seibel: When you were working in those settings did you feel like you hada process that let you estimate how long it’s going to take to build Xamount of software with any kind of accuracy?

Allen: Well, they did. The product-development people certainly did. It wasall tracked, and I’m sure it still is. Part of it would be to statistically get ahandle on the quality of the code. How many bugs showed up this week,yeah. I liked the environment of a product lab because it’s sort of wherethings get real.

Seibel: When you were hiring programmers what did you look for?

Allen: Well, I had a lot of connections in the universities. NYU had somefabulous compiler-writer faculty—that group was really well-trained towrite compiler code.

Seibel: So you could hire people recommended by the professors youknew and trusted. How about when you have to interview someone whodoesn’t come with a recommendation from someone you trust—how doyou figure out in the course of a couple of hours whether they are going tobe a good programmer?

Allen: I always start with interviewing anybody for IBM Research by tryingto find out what they’re excited about. That’s kind of a basic threshold forme. And it doesn’t matter whether it has anything to do with programmingor computers. If they can’t get enthusiastic about something, they’re notgoing to get charged up in a group.