Seibel: Yet there’s often a tension between small, elegant jewels andsprawling, practical balls of mud. A small, perfect jewel is easy to understandand it doesn’t have warts but then you have to build more stuff on top of itto do anything. So everybody reimplements the same things over and overand that leads to a different kind of bloat and ugliness.

Crockford: But that’s not what’s happening. We have a number of Ajaxlibrary developers who are doing that and some of them are getting verysophisticated in their use of the language. And then the communities outthere are building sloppy stuff on top of it and that’s working. So it’s notnecessary for every application programmer to understand how to fullyexploit lambda in order to take advantage of the lambda nature of thelanguage. So we’re already doing that. We don’t need to abandon thelanguage in order to fix that—that’s not where it’s broken.

Where we do have a problem there is that there are too many Ajaxlibraries. That was a consequence of the fact that JavaScript is so powerfuland the need is so profound and that they’re easy to make. So for a whileeverybody was making them. I’ve been expecting that we’re going to have ashake-out but it hasn’t happened yet. So we still have a whole lot oflibraries. So we have an alternative problem now—because there are somany libraries to choose from, developers don’t know which one to use. Ithink there will be a shake-out eventually.

One thing that we’re seeing now is that the Ajax libraries are converging.jQuery came up with a notation for using CSS selectors for getting a list ofobjects from the DOM and then providing methods for manipulating theobjects en masse. And that turns out to be a really good idea and it’ssomething that JavaScript does very effectively. There’s an inefficiency therein that the interface to the DOM is horrible but they hide it all. They’vereally simplified the programming model—it’s brilliant.

So everybody’s doing that now—we’re seeing feature convergence. Whichmakes the problem even harder for the user community because it makes itharder to decide which library to use because they’re all becoming moresimilar. But eventually they’re going to coalesce down to a couple, maybeone. I had been predicting that one of the winners was going to beMicrosoft with their Atlas framework, just because Microsoft is always oneof the winners. But they don’t appear to be getting traction. The openframeworks seem to be doing much better. So I’m expecting one or two ofthe open frameworks will ultimately win.

Seibel: These days you’re a JavaScript architect and evangelist here atYahoo!, so part of your job, presumably, is to tell Yahoo! JavaScriptprogrammers, “Here’s how you should do it.” Does your job also covergeneral good design practice and good coding practice?

Crockford: One of the things I’ve been pushing is code reading. I think thatis the most useful thing that a community of programmers can do for eachother—spend time on a regular basis reading each other’s code. There’s atendency in project management just to let the programmers go offindependently and then we have the big merge and if it builds then we shipit and we’re done and we forget about it.

One of the consequences of that is that if you have weak or confusedprogrammers you’re not aware of their actual situation until much too late.And so the risks to the project, that you’re going to have to build with stuffthat’s bad and the delays that that causes, that’s unacceptable. The otherthing is that you may have brilliant programmers on the project who are notadequately mentoring the other people on the team. Code reading solvesboth of those problems.

Seibel: Can you talk a bit about how you conduct a code reading?

Crockford: At each meeting, someone’s responsible for reading their code,and they’ll walk us through everything, and the rest of us will observe. It’s areally good chance for the rest of the team to understand how their stuff isgoing to have to fit with that stuff.

We get everybody around the table; everybody gets a stack of paper. Wealso blow it up on the screen. And we all read through it together. Andwe’re all commenting on the code as we go along. People say, “I don’tunderstand this comment,” or, “This comment doesn’t seem to describe thecode.” That kind of stuff can be so valuable because as a programmer youstop reading your own comments and you’re not aware that you’remisdirecting the reader. Having the people you work with helping to keepyour code clean is a huge service—you find defects that you never would’vefound on your own.

I think an hour of code reading is worth two weeks of QA. It’s just a reallyeffective way of removing errors. If you have someone who is strongreading, then the novices around them are going to learn a lot that theywouldn’t be learning otherwise, and if you have a novice reading, he’s goingto get a lot of really good advice.

And it shouldn’t be something that we save for the end. Back in the olddays, we would schedule a code reading just as we were finishing a projectand usually it would be canceled because we were late. I now believe thatcode reading should be happening all the time throughout the life of theproject. That’s something that took me a while to figure out but there areso many benefits that come from that.

For one thing it makes it easier to track the project, because we can actuallysee what progress people are making. And we can see much sooner ifthey’re going off the rails or not.

I’ve managed projects where we’re up against a deadline and we had peoplesaying, “Yeah, I’m almost done,” and then you get the code, and there’snothing there, or it’s crap, or whatever, and they’re nowhere close to done.In management, those are the experiences you hate the most and I thinkcode reading is the best way of not getting trapped like that.

Seibel: So say we’re doing a code reading of some of my code. I bringprintouts and we put it up on the screen. Then what? Do I literally read itout loud?

Crockford: Yeah, go through it line by line, and you’ll be doingcommentary on it. This is what’s supposed to be happening here. If we havetime, we’ll go line by line.

Seibel: Do you find that you have to teach people how to do codereadings? I can imagine it’d be hard to find the right balance of being criticalenough to be worthwhile without making the code’s author feel personallyattacked.

Crockford: Yeah, it requires a lot of trust on the part of the teammembers so there have to be clear rules as to what’s in bounds and what’snot. If you had a dysfunctional team, you don’t want to be doing this,because they’ll tear themselves apart. And if you have a dysfunctional teamand you’re not aware of it, this will reveal it pretty quickly. There’s a lot thatyou can learn, a lot that’s revealed by this process. It feels unnatural at first,although once you get into the rhythm of it, it feels extremely natural.

Another aspect is writing your code such that it can be read. Neatnesscounts, as it turns out, and style is important. And all of those things willincrease the quality of the code base going forward and increase thecompetence of the programming community.

Seibel: What makes code readable for you?

Crockford: It happens at a number of levels. The simplest is just beingconsistent in the presentation so you always indent everything properly; youhave white space in all the right places. One habit that I still struggle with,something I learned back in the Fortran days, is I tend to use too many onelettervariable names, which I believe is a bad thing. And I’m trying reallyhard to break it, but it’s difficult—it’s still something I struggle with.

Seibel: How hard is it? Do you write the code and then you come backlater and say, “Oh, look at all these one-character variable names.”?