I always tried to make the whole program better and that would often meanthat even though there was one little problem, I would try to understandthe whole program. I would try to find the problem by reasoning downfrom the top and finding it as opposed to saying, “Oh, this isn’t working. Dosurgery here.” So there were some things where I just took too long andspent too much time trying to import the whole thing into my head, when amore directed approach just to go fix it would do.

But usually when Steve left a project, it was hard to revise the code to makeit do stuff. Whereas I tried to keep things good, but it meant that if aprogram was really big and awful, I would spend a lot of time spinning mywheels before I felt comfortable diving in. But that didn’t happen very oftenbecause often when I debug things, I don’t do it by debugging.

As I mentioned before, there were many bugs that I never had any cluewhere they were. I just get to a point where I say, “This piece of code issupposed to be doing this. This does not look like it’s doing that. I mean,how could anybody have written this complicated bit of code to do thissimple thing?” So I’d rip it out and replace it with a routine that does thesimple thing I thought that piece of code was supposed to do. And theprogram magically works. In retrospect, what had happened is that theprogram had evolved and this little routine kept getting changed. Ratherthan being replaced when the program evolved, somebody was patching itto do different things and missed once.

I never debugged any of that stuff. I hack on it for a day or two doing all ofthis typing and nobody would have a clue of what I’m doing and the programwould get fixed. What a debugger! That is very dangerous because Will’sdictum is basically right, that if you rewrite a hundred lines of code, you maywell have fixed the one bug and introduced six new ones. And at least theone bug you, knew what to look for; you now have to start looking for thesix new ones. And I was just fortunate because I had a very good trackrecord over the years of managing to write code that, for the most part,worked.

Seibel: So you must have had some strategies for reading code. Even ifthere’s no bug but just a big pile of code that you’re going to work on, howdid you tackle that?

Cosell: Not very well, it turns out. One of the reasons why I tend torewrite chunks of code rather than fix them is because I reach points whereI can’t manage to figure it out anymore. I don’t read the code as if it were abook. I try to figure out what the program is doing and then get hints aboutthe code from the top down.

In parallel with reading the program I think about how would I solve thisproblem. Which means I’m looking for certain specific pieces so I can say,“Oh, here’s where the program does it.” Then I can say, in my usualarrogant way, that the guy that wrote this did it wrong. Or at least I nowunderstand that they’re doing this some other way.

So I would go top-down. But some of the guys I knew were spectacularlygood at bottom-up. They would start reading little subroutines andeventually find the one subroutine they needed. But mostly for those kindsof things I was a top-down kind of guy. That is, I’m looking at the programtrying to figure out what the other programmers should have done. Thatwas one of the things that led me to sometimes fix bugs where I didn’tknow what the bug was. I’d hit a place where I say, “This piece of code—as Iunderstand this program now—is supposed to be doing this” and theneither the code I’m looking at doesn’t do that or the code is so complicatedand seems to be doing six other things and it’s not making sense to me.

In either case my usual response at that point is to fix that piece of code sothat it agrees with what I thought was supposed to be happening there inthe program. You can see how fabulously dangerous that can be becausethere is no one correct way to organize a program and if the program wasperfectly well organized but in a different way than I wanted, I have now justkilled the program and now have an incredible avalanche of stuff to fix. But Iwas pretty lucky with that. Usually when I said, “This looks wrong and I’mgoing to fix it” it got fixed. And that was even true from the early days.

The first big program I worked on, the PDP-1 time-sharing system, I wasjust a raw programmer doing college-undergrad programming problems andI moved through the hospital project very quickly, from doing applicationsto coming under the wing of the systems guys. Even though I was sixmonths into being a professional programmer I was perfectly willing to saythat this little piece of the remote process swapper doesn’t look like it’sright and I would rewrite it.

Seibel: In addition to the danger of introducing new bugs, another risk isthat you may have misapprehended what the program is supposed to do.

Cosell: That’s right. The path I took was, if you will, not for the faint atheart. At the time I was 19 years old and that seemed like the only way todo things. I had two convictions, which actually served me well: thatprograms ought to make sense and there are very, very few inherently hardproblems. Anything that looks really hard or tricky is probably more theproduct of the programmer not fully understanding what they needed to doand pounding it with a hammer ’til they got code that looked like it did theright thing.

I don’t know why I had those two convictions. I arrived at BBN with no skillper se, but I had those principles in the back of my head for some reason. Ithought I ought to be able to understand anything and it shouldn’t be sohard. I found that even for the time-sharing system and the IMPs—for all ofthose class of programs, that proved to be true. In general once I had theright understanding of what a program was supposed to do, the pieceswould fall into place. The pieces that didn’t belong would stand out like amiscolored piece in a jigsaw puzzle.

Another principle was I always wanted clean listings. I wanted the thing tobe just right. When you have to fix a bug in a program you never, ever fixthe bug in the place where you find it. My rule is, “If you knew then whatyou know now about the fact that this piece of code is broken, how wouldyou have organized this piece of the routine?” What were you thinkingabout wrong before? Fix the code so that can’t happen. When you finishwith a routine I want every routine you work on to look as if it was justwritten. I do not want to see any evidence of afterthoughts or things gonewrong followed by something to correct the error or a mysterious piece ofcode saying, “This routine returns the wrong value every now and then soI’ve got to fix it.” I don’t want to see any of that. I want to see code thatlooks like through some divine inspiration you got it exactly right the firsttime.

Then I compound that with one other little trick. I got this when I wasworking on D.O.D. projects. They’ll never fund a new project. Both BBNand the government have too much invested in the current program, evenwhen it has limitations that are awful that need to be fixed. The mostcommon one is something that you did that was right when the programstarted is now hopelessly wrong because the program’s use orrequirements or something have evolved. What you’d like to do is rip outthat part of the program and just fix it. And they say, “What is that going toimprove?” You say, “It’s not going to improve anything but it’ll make theprogram better for next week.” Not going to get permission to do that.

The method I took is the sneaky way and this has worked very well for mefor a lot of programs. I do a design of the future version of the program.Knowing what I know now, this is how the program would have looked,now at the program level rather than at a subroutine level. Now when yougo to fix a bug and you have a choice on how to fix it, fix it moving towardthe better model. Don’t just fix it in the shortest way. Don’t just fix it in theway that fits, but move it toward the other model so that over severalmonths instead of the program getting more and more mired in patchesfixing up the stuff that was old and wrong, all the critical parts of theprogram all of a sudden look like they’re the new way of doing things. Oftenyou can get to the point where there are so few places left that still dothings the old way that you can slip in and get those fixed because you’renow not damaging the whole program.