Seibel Peter. Coders at Work

Подождите немного. Документ загружается.

Bernie Cosell

535

I was sort of trying to find out what the basic constants in Will’s mind were

when he put things together. When two time-outs had the same time were

they supposed to be the same or were they coincidentally the same? Who

knows? How many places do you have to change when you want to change

one of the constants? If you discover dynamically that you’re not waiting

long enough for something to happen and it is timing out when it shouldn’t,

you know that you can’t just change that one time-out because these things

are interrelated.

So I made a whole bunch of sharp sign defines, basically, to try to find the

smallest number of independent constants. I remember doing that because

it was just really scary. It was one of the places where I was dabbling in

things that really nobody understood because a lot of those constants Will

had put in intuitively and we had tuned to make work, one by one. The

time-out isn’t big enough and so we would make it bigger, not doing it by

first principles or algebra, but just tuning it until it works.

Seibel: Did you find bugs that way or did you just put it on a more solid

footing so that as things changed, you could change things in a way that

wouldn’t require endless retuning?

Cosell: I don’t recall finding any bugs. But there were undoubtedly some

places where there were timers that now had different values than they

used to, but not operationally significant ones, just defensively different

ones. It was less so that you could change it if you have to; really it was so

that it made the program easier to understand. I hated having a program

that had 200 randomly chosen independent constants scattered throughout

it and knowing that they have something to do with the heartbeat of the

network. I think it simplified some of the code. It made it easier to fathom

what was going on. It also let us use more symbolic constants. Eight times

diameter plus pulse time or something like that would be understandable.

Will was sort of the advanced idea man. I remember complaining to Frank

Heart about this once, that he got to work on the projects right out of the

box because BBN was doing a lot of very cutting-edge stuff and he was

terrific at finding ways to do things that couldn’t be done before.

He was not as good at getting 100 percent done nailed-down code. He was

really good at getting 75 or 80 percent pretty good code that worked most

Bernie Cosell

536

of the time. Will had already gone on to, I think, the TIP, and Dave and I

were still working on the IMP system and that’s when I redid the routing

algorithm because it had funny constants and I didn’t understand it. So it was

still Will’s routing algorithm but recoded with my style. And I think it was a

little more solid. At least I understood if it was going to oscillate, why it was

going to oscillate, because I made it oscillate.

One of the places where Will Crowther and I absolutely differed—and I had

to put in hours and hours of work and even then he was skeptical—was he

believed that when you reassemble a program you add more bugs than you

remove. So he used to keep notebooks with pages and pages of patches. He

would go as long as he could patching the existing system before he had to

reassemble. Those patches were of patches on top of patches and so

complicated that often his prediction was a self-fulfilling prophecy. It was

hard, after all of that, to get it just right so that it turned out to be what the

patches were actually saying.

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

assembler—

Cosell: Right, and a binary image that was running. Then we would have a

paper tape—or sometimes we’d just do it by hand—that plants a jump here

out to a little area where these three lines of code were replaced by these

five lines of code and then it transfers back to the subsequent thing so when

you execute this code it goes off to the patch, executes some stuff, and

comes 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 had

the examine and deposit functions I was so fond of, we actually could build a

little text tape that looked like, “Go to location 12785, value, value, value,

value. Blank line. Go to location 12832, value, value, value, value, value.” If

you had to load the program from scratch you loaded the program and then

you loaded the patch tape when you were done.

Seibel: So at that point you didn’t actually have any source code that would

assemble into the current state of the running binary?

Bernie Cosell

537

Cosell: Exactly right. One of the troubles was we had different copies of

the listings. One of the listings will have an inked mark at some place in the

code where two lines will be crossed out and next to it the replacement

code. Now, did every copy of the listing get that? Will was very good

because he had his notebook and the final say was not a particular listing but

his notebooks. That was his approach.

My approach was that the system should always run out of the box. I do not

want to mark on the assembly listing. When I first came on the project it

was hard to get all of his patches in. We would work all day and then I

would edit and reassemble the system overnight so that the next morning

we had another clean tape and we would start with that. It turns out when

you’re doing it overnight you only have two or three changes and they’re

located so you can read the code as you change it and it makes sense. Of

course, that settled down right away.

So we almost never again had a problem of fixing a bug creating a new one

other than if the patch was wrong. But Will and I were at odds about that

because he was really very fond of patching and staying away from

assembler if you could, partly because it took a lot of time whereas he can

patch and just go on, and partly because he didn’t trust the cycle because

the editing was too scary.

Seibel: Do you consider your work on the IMP one of your important

technical achievements?

Cosell: Oddly enough no. It was an interesting, hard program, but I’d

written Doctor, I was doing Lisp stuff, I’d been czar of the hospital

computer system. Certainly at that point the neatest thing I had worked on

was understanding every line of code in this cutting-edge time-sharing

system. This thing was just a little stand-alone communications processor. It

didn’t have as many interrupt channels as we had on the PDP-1. It didn’t

have to deal with what do you do when you only have 32 swapping slots

and 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 to

do. 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 about

Bernie Cosell

538

the IMP system was how bounded it was. The PDP-1 was basically hard. It

was 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 a

disciplined fashion. They started officially in January; I joined the project in

February and in September it was done. Small value of “done”—we were

still working on it fixing bugs and stuff but it got released in September and

didn’t stop. Not long after that Will went on to his next project and Dave

and 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’t

understand how he hit on the management style of mostly letting us be as

crazy as we were. I’m hard-pressed to remember a software-review

meeting. I’m hard-pressed to remember being hassled for documentation

when the three of us had the program in our heads and couldn’t be

bothered with a lot of that stuff. There was a level of trust and confidence

that the three of us were going to do this thing and he left us alone. In

retrospect, having been a project manager, that’s a stunning thing; that’s just

bizarre. No weekly staff meetings, no PERT charts on the board. Willy was

of course keeping track of what needed to be done and bugs we found and

stuff, 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 of

management bravery.

Another thing that Frank did, on other projects, was design reviews. He had

the most scary design reviews and I actually carried that idea forward.

People would quake in their boots at his design reviews. This was sort of

like taking your orals for your dissertation. He would have a hand-picked

collection of people in the audience and you would have to present your

design. The people he picked were always good. The thing that made his

design 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 part

of it real well and so you kind of slide past that part. You think you got this

right but you didn’t really do the analysis so you don’t know quite what’s

going on. He had an instinct, and it was abetted by having a good crew in

there, of catching you when you were bluffing, catching you when you

hadn’t thought it through.

Bernie Cosell

539

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 focus

in on. I know some people were terrified of it. The trouble is if you were an

insecure programmer you assumed that this was an attack and that you have

now 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 it

wasn’t. The design review was to help you get your program right. There’s

nothing we can do to help you for the parts that you got right and now

what you’ve got is four of the brightest people at BBN helping you fix this

part that you hadn’t thought through. Tell us why you didn’t think it

through. Tell us what you were thinking. What did you get wrong? We have

15 minutes and we can help you.

That takes enough confidence in your skill as an engineer, to say, “Well

that’s wonderful. Here’s my problem. I couldn’t figure out how to do this

and I was hoping you guys wouldn’t notice so you’d give me an OK on the

design review.” The implicit answer was, “Of course you’re going to get an

OK on the design review because it looks OK. Let’s fix that problem while

we’ve got all the good guys here so you don’t flounder with it for another

week or two.”

What you wanted to do with a design review was double-check

that the parts that he thought he had right he did have right and

potentially give him some insight on the parts that he didn’t. Once

I apprehended that—I was only like 20 or 21—that seemed so

obviously right, such an obvious good use of the senior talent

doing the review.

Of course, the design review for the client is different. The design review

for the client is all, “We know it all. It’s all going to be perfect.” But the

internal design review was an opportunity and I was always surprised by

how many people were absolutely scared about the prospect of a design

review. These are good people but they just said, “My design is going to be

torn to shreds.” It’s hard to convince them that it’s won’t get torn to shreds

if it’s any good, that these guys are not vindictive. They’re going to try to

continue the BBN mystique of getting it all right.

Bernie Cosell

540

It’s also hard to tell them that you will never again in your career get this

collection of people willing to spend an hour helping you think through your

design. You’re going to be on your own after this, and that was just a

wonderful experience.

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

or throughout?

Cosell: There weren’t multiple design reviews; the design review was

basically once when the design was considered done.

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

part?

Cosell: Yeah, right. Yeah. Probably some of the coding had been done

because a lot of people, including me, have to start blocking up little bits of

code to see how a thing is actually going to work out. But typically we are in

a cycle where we have to propose things and then we get funded later to do

them. So what we have to do is propose to the client, “This is what we’re

going to do,” and you want a good understanding because the client at this

point is going to give you so much time and so much money and expect it to

work. 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. I

don’t recall Frank stepping into contracts once they were afoot. Certainly

the projects I was working on I can’t remember an ongoing project review

including Frank.

Seibel: You just mentioned Doctor. What was that?

Cosell: When I was working on the PDP-1 time-sharing system, Dan

Murphy and his friends were working on their PDP-1, bringing up this Lisp

system. So I thought I would learn Lisp. That spring, Joe Weizenbaum had

written an article for Communications of the ACM on ELIZA. I thought that

was way cool. And I believed, as I likely still believe now, that anything I can

understand, I can make a computer do. He described how ELIZA works and

I said, “I bet I could write something to do that.” And so I started writing a

Lisp program on Dan Murphy’s PDP-1 system at BBN. I had a Model 33

Teletype that was in my PDP-1 computer room connected to Dan Murphy’s

Bernie Cosell

541

PDP-1 so I could play on his computer from my computer room and

pretend to be working on my system. I wrote that program and got it up

and working. Playing with it was an all-BBN project. People would leave me

comments: “It would be better if you did this” or, “I tried this, and it didn’t

work.” That actually helped spread Weizenbaum’s idea beyond its

boundaries. It was written, at first, in the PDP-1 Lisp. But they were building

a Lisp on the PDP-6 at that point—or maybe the PDP-10. But it was the

Lisp that had spread across the ARPANET. So Doctor went along with it, it

turns out.

I got a little glimmer of fame because Danny Bobrow wrote up “A Turing

Test Passed”. That was one of the first times I actually got some notice for

my stupid hacking: I had left Doctor up. And one of the execs at BBN came

into the PDP-1 computer room and thought that Danny Bobrow was dialed

into that and thought he was talking to Danny. For us folk that had played

with ELIZA, we all recognized the responses and we didn’t think about how

humanlike they were. But for somebody who wasn’t real familiar with

ELIZA, it seemed perfectly reasonable. It was obnoxious but he actually

thought it was Danny Bobrow. “But tell me more about—” “Earlier, you

said you wanted to go to the client’s place.” Things like that almost made

sense in context, until eventually he typed something and he forgot to hit

the go button, so the program didn’t respond. And he thought that Danny

had disconnected. So he called Danny up at home and yelled at him. And

Danny has absolutely no idea what was going on. Except Danny knew about

my terminal. So he came in and tore the typescript off of the thing, to save

it.

It was a very slick version of Weizenbaum’s thing. We improved the scripts

a little bit. Lots of generations of hackers worked on it. And as I say, it

traveled around the Net. And now, I guess, there’s a version of it written in

Emacs macros. But that was my trial by fire in becoming a serious Lisp

programmer.

Seibel: So I’m curious—I’ve observed that often the programmers that

write the hairiest, most complicated code are the ones who can keep a ton

of details in their mind. You obviously had the ability to keep details in your

mind but still cared a lot about making code simple and clear.

Bernie Cosell

542

Cosell: I have to admit that I did both. I would make things simple in the

large. But when I say that programs should be easy, it’s not necessarily the

case 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 was

always in an encapsulated place.

Most of the bad programs I ran into, the ones where I threw things out and

recoded them, there wasn’t a little island of complexity you could try to

understand 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 fresh

out of college, who believe that they understand everything there is to

know about programming. The first is the idea that there are very few

inherently hard programs. If you’re looking at a piece of code and it looks

very hard—if you can’t understand what this thing is supposed to be

doing—that’s almost always an indication that it was poorly thought

through. 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 it

through enough, you’ll find out that it’s easy.

We just did that recently at work. They were working on some big design

project and it was just getting more and more convoluted. So we had a

meeting and started shedding away things. I said, “That seems too

complicated.” And all of a sudden, we had a block diagram for how the thing

would work. And everybody was stunned because they understood how

each block could possibly do its job. We hadn’t done the dull things where

you have to write it all down but they understood that the interfaces were

clean and they could make progress. I’ve done this business long enough to

understand that there are some very hard problems. But very few. It’s

invariably the case that when they think about it harder, it gets easier and all

of a sudden it’s easy to program correctly.

The other rule is to realize that programs are meant to be read. Even

though I’m guilty of writing pages of TECO macros back in my early days, I

very quickly—probably when I was working on the PDP-1 time-sharing

system and the complexity of the time-sharing system started to sink in—

came to the belief that computer-program source code is for people, not

for computers. Computers don’t care. I think it’s a good thing that Perl has

Bernie Cosell

543

both “if” and “unless.” Because it turns out that when you’re getting an

intuition for what something is supposed to be doing, saying “if not some

condition” doesn’t connote the same idea as saying “unless the condition.”

The binary bits are what computers want and the text file is for me. I would

get people—bright, really good people, right out of college, tops of their

classes—on one of my projects. And they would know all about

programming and I would give them some piece of the project to work on.

And we would start crossing swords at our project-review meetings. They

would say, “Why are you complaining about the fact that I have my global

variables here, that I’m not doing this, that you don’t like the way the

subroutines 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 able

to write programs that work. Writing programs that work is a skilled craft

and you’re good at it. Now, you have to learn how to program.” Some of

these guys were fabulously good programmers and they’d never once read a

line of anybody else’s code. In fact, some of them never even read their own

code, so they never had the pain of seeing what happens six months later.

Some would rebel. Some were absolutely convinced that they were good

programmers and I was just some over-the-hill old guy that didn’t know

what he was doing. I know I would have said the same thing not long ago:

“The program works. What is your problem?” When I say, “You don’t get

credit because the program works. We’re going to the next level. Working

programs are a given,” they say, “Oh.” Then they talk to other people and

discover that that’s basically the BBN standard. You can’t explore a new

idea in doing something if you are not craftsman enough to make the

computer do what you had in your mind.

I had a preference of how I liked my global variables and how I liked my

subroutines organized and I got into a multiday battle with one guy where

he said, “Look, it works just fine” and he was such a good programmer that

I didn’t want to pull rank. I felt it important that he understand that I was

not just being a tyrannical turkey; that there was a reason why I wanted him

to do it this other way. He didn’t realize how hard it is to understand a

program with a single C subroutine that’s 42 pages of code long.

Bernie Cosell

544

Seibel: Yikes!

Cosell: I argued with him because I’m a big fan of call-once subroutines

where the only function of the subroutine is to abstract some little part of a

parent subroutine. When you read the parent subroutine—in my approach

to programming—and you get to this place in the code and you get

distracted with the details of this big nexus of stuff, I like to pull that whole

clump out. Now you have a single thing that says, “Sort the table and find

the best route,” even though this is the only place it’s called. Someone

optimizing the code would say, “That shouldn’t be a subroutine. Put that in

line.” But it’s a little subroutine where I can isolate it. It’s obvious what the

inputs are. You can see the algorithm, and only be concerned with that. He

hated when I used to say, “Your routines are too complicated. Your

routines are spanning big chunks of the design” He’d say, “That’s OK

because I can do it all in one routine.”

He rebelled but eventually he did it my way. Then the next task he had was

to take a big piece of code from one of the programmers working on an

earlier effort and make it fit into our system. He worked on that for almost

a week. He so hated the other guy’s program that he complained to my

boss that there aren’t strict enough programming standards in the division.

And the other guy was programming the way he had wanted to program

but with a different spin. So he saw what happens when one very intense,

very good programmer doesn’t segment it down. You get one very long

program—it’s not that the program was spaghetti code but there were just

so many levels of complexity in this one linear suite. He almost pissed me

off because, as I say, he went over my head to demand that the department

had to have standards to not allow that thing to happen.

Seibel: Not realizing that his own previous code would’ve probably fallen

afoul of the same standards?

Cosell: No. He got that. He was a convert. It’s sort of like the guys who

give up smoking and are the most pains in the butt about other people still

smoking. He became one of the strongest guys on my project. He used to

nag me when I wasn’t careful enough—when I compromised. My project

was the first project of its type he had ever worked on. Communications,

real time, all this stuff—all new to him. But he was a smart guy and he went

through this little epiphany and came out of it the programmer I always