Seibel: What tools do you actually use for writing code?

Crockford: I use a little freeware text editor. It doesn’t do anything tricky.That’s about all I need. There is much less need of formal tools like youhave in other languages. The browser just wants a source file, and so yousend it a source file, and the compiler is built into the browser, so there’sreally nothing to do. You don’t have a linker. You don’t have a compiler.You don’t have any of that stuff. It just all runs on the browser.

Seibel: You use JSLint, presumably.

Crockford: I do use JSLint. I use it a lot. I try to use it every time before Irun a program, so if I’ve gone through and I’ve done some edits, I’ll run itthrough JSLint first before I run it.

Seibel: So you edit in your text editor, run JSLint on the program, and thenrun it in a browser. How about debugging?

Crockford: It depends on the browser. If it’s Firefox, then you use Firebug.If it’s IE, then you use the Visual Studio debugger. They’re both actually verygood. We have surprisingly good debuggers in the browser.

I’ve used frameworks in which there were inspectors built out of DOMelements that could then go into objects, and open them up, and inspectthrough that set of frames. But I found I really don’t need that. Just adebugger is enough.

Seibel: Do you ever step through code just as a way of checking it whenyou’re not tracking down a specific bug?

Crockford: Only if I have something that’s really intricate. I’ll step throughit as part of my testing, but generally I only step if I know I have problems.

Seibel: How about other debugging techniques, like assertions, or proofs.Do you use any of those? Do you think in terms of invariants?

Crockford: I like them. I was disappointed that Eiffel was not the winner inthe object-oriented-language contest; that C++ won instead. I thought Eiffelwas a much more interesting language and I liked theprecondition/postcondition contract stuff that it did. I would like to see thatbuilt into my language, whatever language I’m using, but that’s another oneof those ideas that hasn’t really caught on.

Seibel: What’s the worst bug you ever had to track down?

Crockford: It would’ve been a real-time bug. It might’ve been in a videogame. We’ve got interrupts popping all over the place, and no memorymanagement at all, and the program suddenly goes away and you don’tknow why. That kind of stuff is really hard. And generally there wouldn’t bea debugger around either.

At Basic Four we had developed a word-processing terminal. It was a Z80-basedterminal with a full-page display and 64K, which wasn’t nearly enoughmemory for a display that big. And it had a local network connection to ourserver where it would send up the pages.

And we had this problem where every once in a while the screen would goblank. We had this architecture in which we had a line of text and then itwould have a stop code, and then the address of the next line, and a littleDMA processor that would follow those links. And at some point a linkwould go away—there was some race that was happening.

From our perspective, looking at it logically, all of the links were good, butwe hadn’t considered the real-time interaction with the DMA processor,which might not be looking at memory at the same time that we were. I justpuzzled it out. I remember I was working at home that day and I was on thephone with my team and suddenly the lightbulb went on; I knew what theproblem was and I was able to tell them how to fix it and we never had thatproblem again.

In my experience, the worst bugs are the real-time bugs, which have to dowith interactions with multiple threads. My approach to those bugs is toavoid making them. So I don’t like threads. I think threads are an atrociousprogramming model. They’re an occasionally necessarily evil, but they’re notnecessary for most of the things we use threads for.

One of the things I like about the browser model is that we only get onethread. Some people complain about that—if you lock up that thread, thenthe browser’s locked up. So you just don’t do that. There are constantlycalls for putting threads into JavaScript and so far we’ve resisted that. I’mreally glad we have.

The event-based model, which is what we’re using in the browser, worksreally well. The only place where it breaks down is if you have some processthat takes too long. I really like the approach that Google has taken in Gearsto solving that, where they have a separate process which is completelyisolated that you can send a program to and it’ll run there. When it’sfinished, it’ll tell you the result and the result comes back as an event. That’sa brilliant model.

Seibel: Have you ever been interested in formal proofs?

Crockford: I watched it closely during the ’70s, looking to see if they weregoing to come up with anything. And I didn’t see it paying off. Software is socomplicated and can go wrong in so many ways.

Basically, software is the specification for how the software is supposed towork. And anything less than the complete specification doesn’t really tellyou anything about how it’s ultimately going to behave. And that just makessoftware really, really hard.

Seibel: How do you test code? Are you, as they say these days, testinfected?

Crockford: I tend to be more ad hoc. That’s another place where I’mconsidering changing my style, but I haven’t accomplished that yet.

Seibel: There is a JsUnit, right?

Crockford: There is a JsUnit. Testing of UI code is really difficult becauseit’s really dependent on a whole lot of stuff, so breaking it down into unitstends to be less effective. Also, I found because of the style that I’m writingin JavaScript, it doesn’t break in an orderly way into units the way classesdo, so you can think about testing a class in isolation.

In JavaScript, testing a function in isolation maybe doesn’t make much sensebecause there’s the state that it needs in order to be interesting. I haven’tfigured out a sufficiently useful way of testing units of JavaScript yet.

Seibel: In places that have separate QA groups, how should developers andQA groups work together?

Crockford: I’ve had companies where there was an antagonism betweenthe development teams and the testing teams, which I thought wasextremely unhealthy. There was this theory that you keep the two separateand one would rat out the other, basically. And I just think it’s a horriblemodel.

It worked much better when we put the two teams together and made thetesters responsible for helping the developers to make their programsbetter, rather than ratting out the developers. It changed the way theyreported and was much more effective. Also, cycling the developers intotesting, so you weren’t exclusively one or the other.

The place where I found that to be most effective was taking testing, sort of,to the ultimate: going to visit customers. I did some of that early in mycareer and that was a great experience, having to go live with a customerfor a week, helping them to install a new system, and helping them to workout the problems with using it.

It gave me a huge amount of insight into what it’s like to actually use ourstuff and what I want to be doing for the benefit of the people who aregoing to be using my stuff. Going back afterwards, developers who had nothad that experience all seemed arrogant to me in a way which wascompletely inexcusable. The lack of respect they had for the people whoused our stuff was appalling and it was basically a consequence of theirhaving never met those people.

Seibel: Do you consider yourself a scientist, an engineer, an artist, acraftsman, or something else?