Seibel: How do you design code?

Eich: A lot of prototyping. I used to do sort of high-level pseudocode, andthen I’d start filling in bottom up. I do less of the high-level pseudocodebecause I can usually hold it in my head and just do bottom-up until it joins.Often I’m working with existing pieces of code adding some new subsystemor something on the side and I can almost do it bottom-up. When I get introuble in the middle I do still write pseudo-code and just start workingbottom up until I can complete it. I try not to let that take too long becauseyou’ve got to be able to test it; you’ve got to be able to see it run and stepthrough it and make sure it’s doing what it’s supposed to be doing.

Before that level of design, there may be some entity relationships or grossmodularization. There’s probably an algorithm or three that we’re thinkingof where you’re reasoning about the complexity of it—is it linear? Is itconstant? Every time I’ve written some kind of linear search that’s going tocompound quadratically, and unleashed it on the Web, web developers havefound that to be a problem. They’ve written enough stuff it stresses it. Sowe tend to do a lot of data structures that are constant time. And eventhen, constant can be not one—it can be big enough that you care.

So we do lots of prototyping, we do lots of bottom-up and top-down andthey meet in the middle. And I think actually we, at Mozilla, don’t do enoughrewriting. We’re very conservative. We are open source, so we havecommunity we try to build and bring new people into. We certainly havevalue that users benefit from, and we don’t want to take a three-year breakrewriting, which is what would happen if we tried too much.

But if you really are trying to move a needle and you don’t know exactlywhat you’re doing, rewrite. It’s going to take several tries to know what thehell you’re doing. And then when you have a design more firm you’ll stickwith it and you’ll start patching it more, and you’ll get to this mature statewhere we creak with patches. It’s kind of an evolutionary dead-end forcode. You know, maybe it’s a good sunk cost and you can stand on it foryears. Maybe it’s this thing that’s crying out for replacement. Maybe in theopen-source world some better standard library has emerged.

And that gets back to the craft of programming, I think. You don’t just writecode based on some old design. You want to keep practicing, and thepracticing involves thinking about design and feeding back your experiencein coding to the design process.

I have this big allergy to ivory-tower design and design patterns. PeterNorvig, when he was at Harlequin, he did this paper about how designpatterns are really just flaws in your programming language. Get a betterprogramming language. He’s absolutely right. Worshipping patterns andthinking about, “Oh, I’ll use the X pattern.”

Seibel: So newer experiences can show you better ways going forward. Butwhat about when writing the code shows you big flaws in your existingdesign?

Eich: That does happen. It happens a lot. Sometimes it’s difficult to throwout and go back to square one. You’ve already made commitments, and youget into this trap. I did this with JavaScript. In a great big hurry, I wrote abyte-code interpreter. Even at the time I knew I was going to regret someof the things I’d done. But it was a design that was understandable to otherpeople and I could hope to get other people helping me work on. So Iquestion design all the time. I just realize that we don’t always get the luxuryof revisiting our deepest design decisions. And that is where we thenattempt to do a big rewrite, because you really would have a hard timeincrementally rewriting to change deep design decisions.

Seibel: How do you decide when it’s right to do a big rewrite? Thanks toJoel Spolsky, Netscape is in some ways the poster child for the dangers ofthe big rewrite.

Eich: There was an imperative from Netscape to make the acquisition thatwaved the Design Patterns book around feel like they were winners by usingtheir new rendering engine, which was like My First Object-OrientedRendering Engine. From a high level it sounded good; it used C++ anddesign patterns. But it had a lot of problems.

But the second reason we did the big rewrite—I was in mozilla.org and Ireally was kind of pissed at Netscape, like Jamie, who was getting ready toquit. I thought, you know, we need to open up homesteading space to newcontributors. We can’t do it with this old hairball of student code from1994. Or my fine Unix kernel-style interpreter code.

We needed to do a fairly big reset. Yeah, we were going to be four yearsfrom shipping. At that point I don’t think we were telling upper managementthat because they didn’t want to hear it, so we were optimizing to them.And that cost some of the management their heads. Though they all madeout fabulously on the options—much better than I did. But for Mozilla thatwas the right trade.

We were lucky in hindsight, because we could have had a more rapidevolution of the Web. Microsoft was—some people claim this was due tothe antitrust case more than their nature—inclined to sit on the Web andstagnate it. So that gave us time to wave the standards flag—which is twoedgedand half bullshit—and go rewrite. Like Joel, I’m skeptical of rewrites. Ithink it’s rare to find that kind of an alignment of interests and get enoughfunding to live through it and not miss the market. The exceptions are veryrare.

The rewrites I was speaking of earlier, though, were when you’reprototyping. That’s critical and smaller-scale. It may be a cross-cuttingchange to a big pile of code so it’s small in lines, but it’s big in reach and allthe invariants you have to satisfy. Or maybe it’s a new JIT or whatever, andthat you can get away with.

Seibel: Have you ever done any literate programming, a la Knuth?

Eich: I followed the original stuff. It was very neat. I liked it. It was wordretrieval. He had some kind of a hash-trie data structure and it was allliterately programmed. Then Doug McIlroy came along and did it all with apipeline.

Our programs are heavily commented but we don’t have any way ofextracting the prose and somehow making it be checked by humans, if notautomatically, against the code. Python people have done some moreinteresting work there. I have not done anything more than heavilycomment. I do go back and maintain comments—it’s a real pain andsometimes I don’t do it and then I regret it because somebody gets a bumsteer.

I actually like McIlroy’s rejoinder. It wasn’t a rebuttal of literateprogramming—but it was kind of. You don’t want to write too many words,prose or code. In some ways the code should speak for itself at the smalllevel. It’s at the bigger level, the big monster function or the moduleboundary, that you need docs. So doc comments or things like them—docstrings. Embedding the test in the comment. I guess that’s the big Pythonthing. That’s good.

There is something to literate programming, especially these integratedtests and doc strings. I’d like to see more of that supported by languages.We tried to add doc comments of some sort to ES4 with first-classmetadata hooks or reflection hooks and it was just impossible to geteverybody to agree.

Seibel: Do you read code you’re not working on?

Eich: I do it as part of my job. Code review is a mandatory pre-check-instep, mostly to compensate for Netscape’s bad hiring, but we kept it andstill use it for integration review. We have a separate “super review” forwhen you’re touching a lot of modules and you don’t know all the hiddeninvariants that Joe Schmoe, who no longer works on Mozilla, knew in hishead. Somebody else may have figured them out so you have somebodyexperienced to look at the big picture. Sometimes you can bypass it if youknow what you’re doing and you’re in the sort of Jedi council, but we’re nottrying to cheat on it too much.