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.
Seibeclass="underline" 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.
Seibeclass="underline" Do you consider yourself a scientist, an engineer, an artist, a craftsman, or something else?
Crockford: I think of myself as a writer. Sometimes I write in English and sometimes I write in JavaScript.
It all comes down to communication and the structures that you use in order to facilitate that communication. Human language and computer languages work very differently in many ways, but ultimately I judge a good computer program by its ability to communicate with a human who reads that program. So at that level, they’re not that different.
Seibeclass="underline" And if it can communicate well to a human, you feel like the communicating-with-the-computer part will fall out?
Crockford: You hope so. Computers are arbitrary and not very smart, so you have to make special efforts to make sure that they get it. Because that’s so hard, it’s easy to overlook the other part, but I think it is at least as important.
Seibeclass="underline" So Dijkstra had a famous paper, “On the cruelty of really teaching computing science,” that basically said computer programming is a branch of applied math. Do you agree?
Crockford: Mathematics is important in programming, but it’s just one of a lot of things that are important. I think if you overemphasize the math then you underemphasize stuff which might be even more important, such as literacy.
I mentioned I wanted to have the hiring requirement that they had to have read Knuth and I couldn’t do that because I couldn’t find enough people who had. The other thing I wanted was that they be really literate in whatever language they write to other humans. I want people who can write, because we spend a lot of time writing to each other. We’re writing email or documentation. We’re writing plans. We’re writing specifications. I want to know that the people on my team are capable of doing that, and that turns out to be a really difficult skill. So I would actually rather see people start as English majors than as math majors to get into programming.
Seibeclass="underline" I think Dijkstra had another quote about that along the lines of, “If you can’t write in your native language, give it up.”
Crockford: I agree with that one.
Seibeclass="underline" An aspect of programming that you seem to keep running up against is that while we are unbound by physical constraints we get tied down by accidents of history. A lot of your proposals for subsetting JavaScript and your version of HTML5 seem to be attempts to fix these kinds of historical accidents.
Crockford: Yeah, and some of it is quixotic. I know that a lot of the things that I’m hoping to accomplish are not achievable. I’m aware of that. But every once in a while something works. Like when XML was proposed as a data-interchange format, my first impression of that was, “My god, this is way, way, way too complicated. We don’t need all of this stuff just to move data back and forth.” And so I proposed another way to do it, and it won. JSON is now the preferred way of doing data transfer in Ajax applications and it’s winning in a whole lot of other applications. And it’s just really simple. So that restores my faith in humanity, that maybe we can finally get some of these things right.
But you can’t have everybody going off, making up their own thing. That doesn’t work. That doesn’t do anybody any good. But one person has to make up a thing and everyone else has to figure out how to agree which one of those we’re all going to get behind. JSON was a different kind of accident of history.
Seibeclass="underline" Overall, do you think that the software industry is a brilliant engine of innovation or a horrible mess?
Crockford: I’m trying to think of a nice way to say, “Horrible mess.” I’d think generally software has gotten better. Not at the same pace that Moore lets the hardware got better. We track way, way slow compared to him, so it takes us 20 years to double our efficiency in software development. But we have seen improvement. Most of our improvement is due to the fact that we don’t have to make it fit anymore. We don’t have to make it fast anymore. So that should have liberated us to just making it good. But we don’t spend enough time doing that, I think.
Seibeclass="underline" So if we are, however nicely you put it, a horrible mess, what could we do to not be such a mess?
Crockford: That’s what I’m trying to figure out. A lot of it I think has to do with the way that we create standards. The reason why things are working as well as they are now is because the Net works; all the benefits that came, came from being able to tie everything together and have that happen pretty reliably.
But you don’t have to scratch it very deep to find places where we got that wrong, where we could’ve got it better. The dilemma is, how do we fix this stuff in place? Anytime we change a software standard, it’s an act of violence. It is disruptive. It will cause stuff to fail. It will cause cost and harm to people. So we need to be really careful when we revise the standards because there is that cost. We have to make sure that we’re adding so much value to offset that cost. From what I see of the way that standards are being manipulated right now, that’s not occurring. Standard changes are being motivated by “we want to do it” or “because it’d be neat” or some other motivation which is not necessarily closely related to creating a lot of value for the world. So I’m struggling with that. How do we get better at that?
Seibeclass="underline" You seem to lean toward specifying less. That, obviously, is a way to avoid over specifying things and standardizing things that you’re going to regret later. But if less is specified in standards, then people have to make more stuff up and you’re going to have a big pile of de facto standards as people try to settle on OK ways of getting stuff done. Is making standards simpler really going to fix the problem, if the complexity just pops up elsewhere?
Crockford: What we really need to be doing is getting better at predicting what we’re really going to need in the future. Maybe we have to wait for time travel before we finally start getting this stuff right. In the meantime, I look on that experimentation and proliferation of possible approaches as a positive thing in that maybe the right approach to take to standardization is to figure out which of those are the best thought out, which are the most maintainable, which are the most growable, and pick that. Rather than a standards committee trying to guess the best way to do it, we pick from examples in the marketplace what is actually demonstrably the best way to do it.