Seibel: So you had an original source listing that you could feed to anassembler—

Cosell: Right, and a binary image that was running. Then we would have apaper tape—or sometimes we’d just do it by hand—that plants a jump hereout to a little area where these three lines of code were replaced by thesefive lines of code and then it transfers back to the subsequent thing so whenyou execute this code it goes off to the patch, executes some stuff, andcomes back.

Seibel: So the paper tape held the binary version of the patch?

Cosell: Yeah. Later on, when I built a little interactive debugger that hadthe examine and deposit functions I was so fond of, we actually could build alittle text tape that looked like, “Go to location 12785, value, value, value,value. Blank line. Go to location 12832, value, value, value, value, value.” Ifyou had to load the program from scratch you loaded the program and thenyou loaded the patch tape when you were done.

Seibel: So at that point you didn’t actually have any source code that wouldassemble into the current state of the running binary?

Cosell: Exactly right. One of the troubles was we had different copies ofthe listings. One of the listings will have an inked mark at some place in thecode where two lines will be crossed out and next to it the replacementcode. Now, did every copy of the listing get that? Will was very goodbecause he had his notebook and the final say was not a particular listing buthis notebooks. That was his approach.

My approach was that the system should always run out of the box. I do notwant to mark on the assembly listing. When I first came on the project itwas hard to get all of his patches in. We would work all day and then Iwould edit and reassemble the system overnight so that the next morningwe had another clean tape and we would start with that. It turns out whenyou’re doing it overnight you only have two or three changes and they’relocated so you can read the code as you change it and it makes sense. Ofcourse, that settled down right away.

So we almost never again had a problem of fixing a bug creating a new oneother than if the patch was wrong. But Will and I were at odds about thatbecause he was really very fond of patching and staying away fromassembler if you could, partly because it took a lot of time whereas he canpatch and just go on, and partly because he didn’t trust the cycle becausethe editing was too scary.

Seibel: Do you consider your work on the IMP one of your importanttechnical achievements?

Cosell: Oddly enough no. It was an interesting, hard program, but I’dwritten Doctor, I was doing Lisp stuff, I’d been czar of the hospitalcomputer system. Certainly at that point the neatest thing I had worked onwas understanding every line of code in this cutting-edge time-sharingsystem. This thing was just a little stand-alone communications processor. Itdidn’t have as many interrupt channels as we had on the PDP-1. It didn’thave to deal with what do you do when you only have 32 swapping slotsand you have 40 people logged on.

The three of us got along famously, so it was fun and it was challenging.There were things about debugging it and implementing it that were hard todo. But hard to say that I would’ve thought it was the crown of my career.It was just the next program. The other thing that was anticlimactic aboutthe IMP system was how bounded it was. The PDP-1 was basically hard. Itwas a time-sharing system and it had to evolve over time.

The thing about the IMP system that was so neat is how we did it in such adisciplined fashion. They started officially in January; I joined the project inFebruary and in September it was done. Small value of “done”—we werestill working on it fixing bugs and stuff but it got released in September anddidn’t stop. Not long after that Will went on to his next project and Daveand I continued with it and somebody new came in.

The person I have to give a lot of credit to is Frank Heart. I don’tunderstand how he hit on the management style of mostly letting us be ascrazy as we were. I’m hard-pressed to remember a software-reviewmeeting. I’m hard-pressed to remember being hassled for documentationwhen the three of us had the program in our heads and couldn’t bebothered with a lot of that stuff. There was a level of trust and confidencethat the three of us were going to do this thing and he left us alone. Inretrospect, having been a project manager, that’s a stunning thing; that’s justbizarre. No weekly staff meetings, no PERT charts on the board. Willy wasof course keeping track of what needed to be done and bugs we found andstuff, but the lack of oversight structure for that was pretty impressive.Throwing us together and telling us to go do it was, I think, a stroke ofmanagement bravery.

Another thing that Frank did, on other projects, was design reviews. He hadthe most scary design reviews and I actually carried that idea forward.People would quake in their boots at his design reviews. This was sort oflike taking your orals for your dissertation. He would have a hand-pickedcollection of people in the audience and you would have to present yourdesign. The people he picked were always good. The thing that made hisdesign reviews so scary is he knew when you were bluffing.

I’m sure you’ve done design reviews where you didn’t work on some partof it real well and so you kind of slide past that part. You think you got thisright but you didn’t really do the analysis so you don’t know quite what’sgoing on. He had an instinct, and it was abetted by having a good crew inthere, of catching you when you were bluffing, catching you when youhadn’t thought it through.

The parts that you did absolutely fine hardly got a mention. We all said,“Oh.” But the part that you were most uncomfortable with, we would focusin on. I know some people were terrified of it. The trouble is if you were aninsecure programmer you assumed that this was an attack and that you havenow been shown up as being incompetent, and life sucks for you.

The reality—I got to be on the good side of the table occasionally—was itwasn’t. The design review was to help you get your program right. There’snothing we can do to help you for the parts that you got right and nowwhat you’ve got is four of the brightest people at BBN helping you fix thispart that you hadn’t thought through. Tell us why you didn’t think itthrough. Tell us what you were thinking. What did you get wrong? We have15 minutes and we can help you.

That takes enough confidence in your skill as an engineer, to say, “Wellthat’s wonderful. Here’s my problem. I couldn’t figure out how to do thisand I was hoping you guys wouldn’t notice so you’d give me an OK on thedesign review.” The implicit answer was, “Of course you’re going to get anOK on the design review because it looks OK. Let’s fix that problem whilewe’ve got all the good guys here so you don’t flounder with it for anotherweek or two.”

What you wanted to do with a design review was double-check that the parts thathe thought he had right he did have right and potentially give him some insighton the parts that he didn’t. Once I apprehended that—I was only like 20 or21—that seemed so obviously right, such an obvious good use of the seniortalent doing the review.

Of course, the design review for the client is different. The design reviewfor the client is all, “We know it all. It’s all going to be perfect.” But theinternal design review was an opportunity and I was always surprised byhow many people were absolutely scared about the prospect of a designreview. These are good people but they just said, “My design is going to betorn to shreds.” It’s hard to convince them that it’s won’t get torn to shredsif it’s any good, that these guys are not vindictive. They’re going to try tocontinue the BBN mystique of getting it all right.