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 you have in other languages. The browser just wants a source file, and so you send it a source file, and the compiler is built into the browser, so there’s really 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 I run a program, so if I’ve gone through and I’ve done some edits, I’ll run it through JSLint first before I run it.

Seibel: So you edit in your text editor, run JSLint on the program, and then run 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 very good. We have surprisingly good debuggers in the browser.

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

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

Crockford: Only if I have something that’s really intricate. I’ll step through it 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 in the object-oriented-language contest; that C++ won instead. I thought Eiffel was a much more interesting language and I liked the precondition/postcondition contract stuff that it did. I would like to see that built into my language, whatever language I’m using, but that’s another one of 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 video game. We’ve got interrupts popping all over the place, and no memory management at all, and the program suddenly goes away and you don’t know why. That kind of stuff is really hard. And generally there wouldn’t be a debugger around either.

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

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

From our perspective, looking at it logically, all of the links were good, but we 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 just puzzled it out. I remember I was working at home that day and I was on the phone with my team and suddenly the lightbulb went on; I knew what the problem was and I was able to tell them how to fix it and we never had that problem again.

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

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

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

Seibel: Have you ever been interested in formal proofs?

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

Basically, software is the specification for how the software is supposed to work. And anything less than the complete specification doesn’t really tell you anything about how it’s ultimately going to behave. And that just makes software 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’m considering 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 because it’s really dependent on a whole lot of stuff, so breaking it down into units tends to be less effective. Also, I found because of the style that I’m writing in JavaScript, it doesn’t break in an orderly way into units the way classes do, so you can think about testing a class in isolation.

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

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

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

It worked much better when we put the two teams together and made the testers responsible for helping the developers to make their programs better, rather than ratting out the developers. It changed the way they reported and was much more effective. Also, cycling the developers into testing, 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 my career and that was a great experience, having to go live with a customer for a week, helping them to install a new system, and helping them to work out the problems with using it.

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

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