It’s also hard to tell them that you will never again in your career get thiscollection of people willing to spend an hour helping you think through yourdesign. You’re going to be on your own after this, and that was just awonderful experience.

Seibel: How often were these design reviews? At the beginning of a projector throughout?

Cosell: There weren’t multiple design reviews; the design review wasbasically once when the design was considered done.

Seibel: So the design was done before you had really started the codingpart?

Cosell: Yeah, right. Yeah. Probably some of the coding had been donebecause a lot of people, including me, have to start blocking up little bits ofcode to see how a thing is actually going to work out. But typically we are ina cycle where we have to propose things and then we get funded later to dothem. So what we have to do is propose to the client, “This is what we’regoing to do,” and you want a good understanding because the client at thispoint is going to give you so much time and so much money and expect it towork. So it was typically at that point, we are about to finalize the proposal,we are going to have the technical description of what we’re going to do.Now we sit down for the design review to make sure we understand it. Idon’t recall Frank stepping into contracts once they were afoot. Certainlythe projects I was working on I can’t remember an ongoing project reviewincluding Frank.

Seibel: You just mentioned Doctor. What was that?

Cosell: When I was working on the PDP-1 time-sharing system, DanMurphy and his friends were working on their PDP-1, bringing up this Lispsystem. So I thought I would learn Lisp. That spring, Joe Weizenbaum hadwritten an article for Communications of the ACM on ELIZA. I thought thatwas way cool. And I believed, as I likely still believe now, that anything I canunderstand, I can make a computer do. He described how ELIZA works andI said, “I bet I could write something to do that.” And so I started writing aLisp program on Dan Murphy’s PDP-1 system at BBN. I had a Model 33Teletype that was in my PDP-1 computer room connected to Dan Murphy’sPDP-1 so I could play on his computer from my computer room andpretend to be working on my system. I wrote that program and got it upand working. Playing with it was an all-BBN project. People would leave mecomments: “It would be better if you did this” or, “I tried this, and it didn’twork.” That actually helped spread Weizenbaum’s idea beyond itsboundaries. It was written, at first, in the PDP-1 Lisp. But they were buildinga Lisp on the PDP-6 at that point—or maybe the PDP-10. But it was theLisp that had spread across the ARPANET. So Doctor went along with it, itturns out.

I got a little glimmer of fame because Danny Bobrow wrote up “A TuringTest Passed”. That was one of the first times I actually got some notice formy stupid hacking: I had left Doctor up. And one of the execs at BBN cameinto the PDP-1 computer room and thought that Danny Bobrow was dialedinto that and thought he was talking to Danny. For us folk that had playedwith ELIZA, we all recognized the responses and we didn’t think about howhumanlike they were. But for somebody who wasn’t real familiar withELIZA, it seemed perfectly reasonable. It was obnoxious but he actuallythought it was Danny Bobrow. “But tell me more about—” “Earlier, yousaid you wanted to go to the client’s place.” Things like that almost madesense in context, until eventually he typed something and he forgot to hitthe go button, so the program didn’t respond. And he thought that Dannyhad disconnected. So he called Danny up at home and yelled at him. AndDanny has absolutely no idea what was going on. Except Danny knew aboutmy terminal. So he came in and tore the typescript off of the thing, to saveit.

It was a very slick version of Weizenbaum’s thing. We improved the scriptsa little bit. Lots of generations of hackers worked on it. And as I say, ittraveled around the Net. And now, I guess, there’s a version of it written inEmacs macros. But that was my trial by fire in becoming a serious Lispprogrammer.

Seibel: So I’m curious—I’ve observed that often the programmers thatwrite the hairiest, most complicated code are the ones who can keep a tonof details in their mind. You obviously had the ability to keep details in yourmind but still cared a lot about making code simple and clear.

Cosell: I have to admit that I did both. I would make things simple in thelarge. But when I say that programs should be easy, it’s not necessarily thecase that specific pieces of the functionality of the program have to be easy.I could write some very complicated code to do the right thing, right there,code that people would cringe at and not be willing to touch. But it wasalways in an encapsulated place.

Most of the bad programs I ran into, the ones where I threw things out andrecoded them, there wasn’t a little island of complexity you could try tounderstand and fix, but the complexity had oozed through the program.

I have a couple of rules that I try to impress on people, usually people freshout of college, who believe that they understand everything there is toknow about programming. The first is the idea that there are very fewinherently hard programs. If you’re looking at a piece of code and it looksvery hard—if you can’t understand what this thing is supposed to bedoing—that’s almost always an indication that it was poorly thoughtthrough. At that point you don’t roll up your sleeves and try to fix the code;you take a step back and think it through again. When you’ve thought itthrough enough, you’ll find out that it’s easy.

We just did that recently at work. They were working on some big designproject and it was just getting more and more convoluted. So we had ameeting and started shedding away things. I said, “That seems toocomplicated.” And all of a sudden, we had a block diagram for how the thingwould work. And everybody was stunned because they understood howeach block could possibly do its job. We hadn’t done the dull things whereyou have to write it all down but they understood that the interfaces wereclean and they could make progress. I’ve done this business long enough tounderstand that there are some very hard problems. But very few. It’sinvariably the case that when they think about it harder, it gets easier and allof a sudden it’s easy to program correctly.

The other rule is to realize that programs are meant to be read. Even thoughI’m guilty of writing pages of TECO macros back in my early days, I veryquickly—probably when I was working on the PDP-1 time-sharing system and thecomplexity of the time-sharing system started to sink in—came to the beliefthat computer-program source code is for people, not for computers. Computersdon’t care. I think it’s a good thing that Perl has both “if” and “unless.”Because it turns out that when you’re getting an intuition for what somethingis supposed to be doing, saying “if not some condition” doesn’t connote thesame idea as saying “unless the condition.”

The binary bits are what computers want and the text file is for me. I wouldget people—bright, really good people, right out of college, tops of theirclasses—on one of my projects. And they would know all aboutprogramming and I would give them some piece of the project to work on.And we would start crossing swords at our project-review meetings. Theywould say, “Why are you complaining about the fact that I have my globalvariables here, that I’m not doing this, that you don’t like the way thesubroutines are laid out? The program works.”

They’d be stunned when I tell them, “I don’t care that the program works.The fact that you’re working here at all means that I expect you to be ableto write programs that work. Writing programs that work is a skilled craftand you’re good at it. Now, you have to learn how to program.” Some ofthese guys were fabulously good programmers and they’d never once read aline of anybody else’s code. In fact, some of them never even read their owncode, so they never had the pain of seeing what happens six months later.