So when they ask, “How long is it going to take you to put this change in?”you have three answers. The first is the absolute shortest way, changing theone line of code. The second answer is how long it would be using mysimple rule of rewriting the subroutine as if you were not going to makethat mistake. Then the third answer is how long if you fix that bug if youwere actually writing this subroutine in the better version of the program.So you make your estimate someplace between those last two and thenevery time you get assigned a task you have a little bit of extra time availableto make the program better. I think that that makes an incredible difference.It makes for programs that evolve cleanly. It’s amazing to have a programthat’s still in version one but it’s like Washington’s hammer. It’s now a reallysleek new thing because all the key parts have gotten fixed without anyproject manager having to actually authorize you to go rip out the guts andgo fix it.

Seibel: Have you heard of refactoring?

Cosell: No, what is that?

Seibel: What you just described. I think now there’s perhaps a bit moreacceptance, even among the project managers of this idea.

Cosell: Oh, that’s good because I used to need a bug that—I used to needa reason to change the piece of the code to do what you just said because Icould never get permission just to rewrite it to make it cleaner. So I wouldhave to wait till a bug or an improvement request came along touching thatpart of code, but then I would do exactly that. I guess the thing aboutrefactoring is that you have spend some time thinking about what the righttarget is because it won’t do to refactor and have different people aiming indifferent directions or to have the target not be the right thing.

I never did that with a name; it just seemed like the only way I could do twothings: manage the complexity and get a program that you didn’t have tothrow out and code over. The PDP-1 taught me that. It ran for a lot ofyears and it was such a huge project. It took three or four guys to write thefirst two versions of it and there was no way to throw it out, but it had toget better.

Seibel: How do you hire programmers? How do you recognize thetalented ones?

Cosell: I couldn’t ever get into the standard interviewing paradigm. Peopletalk about—and I think Microsoft was famous for this—giving them littleproblems to solve. I seem to have taken a more intuitive approach. Ibasically glanced at the guy’s—or girl’s—résumé to get a feel for whetherthey felt like my type of person. Often the résumés were useless becausethey were just college seniors about to graduate. You read between thelines that this fancy-looking project was really a class project for somecourse in something or other. But I used to talk to them and just get a feelwhether they had somehow the kind of inquiring, curious, precise kind ofmind that I had grown to expect people around me to have.

What were their other interests, their nonprofessional interests? Did theyshow both aptitude for picking things up, and curiosity? It was kind ofslapdash how I did all of that. I had this idealized image of a BBN-qualityperson, some vague thing about aptitude, curiosity, quickness of learning,interested in lots of different things, and kind of broadly based. I used to goon a hunt to see if I got the impression that this person was going to beBBN-quality folk.

Seibel: As you mentioned, Microsoft is famous for asking puzzle-typequestions. And you like puzzles. What do you think of that as a way ofgauging someone’s potential?

Cosell: Carefully chosen, I think it has potential. Not because the personsolves the puzzle, but if it gives you a glimmer as to how they organizesomething to approach it. I have never used it. I would certainly not havehanded somebody one of the little tchotchke puzzles and watched themwhile they tried to put it back together again. The problem is that a lot ofthese puzzles require different styles of solution, and either you know thator you don’t. That’s not so good because I don’t want somebody who’sreally good at doing a sliding-block puzzle because they happen to knowsome good tricks for doing that.

BBN spent a lot of its time sailing in unknown waters, doing things thathadn’t been done, that we didn’t know how to do. And that requires both adegree of daring, because it’s not so easy, and a degree of skill in order tonot founder. That’s the kind of thing I’m looking for, not looking forsomebody with a knack for solving a particular puzzle but, thrown into thiscomplicated thing that they have a need to deal with, can they approach itreasonably?

A case in point was when the Rubik’s Cubes arrived. We had just heardrumors about this wonderful puzzle and one of the guys was on a businesstrip to England and brought back a satchel of them. No books, nodocumentation, not yet a phenomenon in the U.S. at all. Just a strange littlegroup theoretic puzzle. And we started to play with it. Several of us solvedthe puzzle in different ways, but it was interesting that we were able to copewith a puzzle like that. It’s just that that group of BBN people back then hadthe right stuff. That was what I used to look for.

I don’t know whether Microsoft’s little quizzes—and I’ve heard that Googlehas an aptitude test too, or something—I don’t know if those can give you ahint that this person has the right spark. But that’s what I used to look for.Does this person look like they’re ready to be BBN-quality folk? Often Iwould say no. They’re perfectly good, they’re terrific engineers, but as we’retalking I’m not getting that spark. My approach was to look for the spark,and I don’t know how I did it.

Seibel: Do you think programming is a young person’s game?

Cosell: I think that may be the case. I can even see, as I look back at someof the projects I worked on toward the end of my career at BBN, that thepeople I had doing the work for me were doing things that I couldn’tpossibly have done. One of the guys working for me thought that using Tclwould be a neat thing for part of the interface, so in a day and a half helearned enough Tcl to bring the thing up and make it work, which I don’tthink I could’ve done. It was amusing for me to think in the back of my head,“Gee, I used to be able to do things like that.”

I think that the actual production of code—of working, logical, goodcode—requires an intensity and a mental agility in terms of picking up newthings that I, at least, find hard to do now. The other side of the coin isthat you get a certain wisdom about things that you certainly didn’t have whenyou were younger. I know better now how to do things. So I find a better mix isto be able to give young and active people guidance. I think that by and largethe sort of programming that I’ve been talking about is similar to the old sawabout mathematics, that most mathematicians do most of their best work wellbefore they’re 30. The kind of intensity, the kind of focus that you need to doreally cutting-edge mathematics is probably similar to what you need to do thekind of crazy programming I used to do back when I was young.

Seibel: One part of the intensity is that it’s simply physically draining towork long hours. Are long hours necessary or are they just a side effect ofthe fact that we love it?

Cosell: I think that’s a personality side effect. The question of whether youcan put something down and come back to it or whether you are compelledto stick with it and finish it is more of a personality thing. There werecertainly many people I knew of at BBN out in the brilliant end of thespectrum who were perfectly able to work normal hours and not beinterested in coming in on weekends. Then, of course, there were the otherpeople who were at the lunatic fringe—for a while I was sleeping in thecomputer room because it took me too long to drive back to myapartment. I would just take a nap in the computer room and I have no ideahow crazy people thought I was for doing that. But I don’t think that isnecessary; I think it’s a byproduct of the fact that doing the kind of thingthat we do is pretty exciting, especially when it starts to come together.