Peter Seibel - Coders at Work - Reflections on the craft of programming

Seibel:And how big was the development team?

Zawinski:I think there were like 70 people at the company so probably; I don’t know, 40 or so on the development team. The Energize team was maybe 25 people, 20. It was divided up into pretty distinct areas. There were the folks working on the compiler side of things and the back-end database side of things. The GUI stuff that wasn’t Emacs. And then there was, at one point, me and two or three other people working on integrating Emacs with the environment. That eventually turned into mostly me working on mostly Emacs stuff, trying to make our Emacs 19 be usable, be an editor that doesn’t crash all the time, and actually runs all the Emacs packages that you expect it to run.

Seibel:So you wanted the Emacs included in your product to be a fully capable version of Emacs.

Zawinski:The original plan was that we wouldn’t include Emacs with our product. You have Emacs on your machine already and you have our product and they work together. And you had GCC on your machine already and our product, and they work together. I think one of the early code names for our product was something like Hitchhiker because the idea was that it would take all the tools that you already have and integrate them—make them talk to each other by providing this communication layer between them.

That didn’t work out at all. We ended up shipping our version of GCC and GDB because we couldn’t get the changes upstream fast enough, or at all in some cases. And same thing with Emacs. So we ended up shipping the whole thing. We ended up going down the path of, “Well, we’re replacing Emacs. Shit. I guess we have to do that so we better make it work.” One thing I spent a bunch of time on was making the vi emulation mode work.

Seibel:And that’s several weeks of your life you’re never going to get back.

Zawinski:That’s true, yeah. It was challenging. I think it ended up working OK. The real problem with that wasn’t so much that it was emulating vi wrong as that vi users quit and restart vi all the time. And no amount of coding on my part is going to get them out of that mindset. So they’re like, “I expected this to launch in half a second and it’s taking 14 seconds. That’s ridiculous. I can’t use this.”

Seibel:Why did you leave Lucid?

Zawinski:Lucid was done. There’d been a bunch of layoffs. I sent mail to a bunch of people I know saying, “Hey, looks like I’m going to need a new job soon” and one of those people was Marc Andreessen and he said, “Oh, funny you should mention that, because we just started a company last week.” And that was that.

Seibel:So you went to Netscape. What did you work on there?

Zawinski:I pretty much started right away doing the Unix side of the browser. There had been maybe a few days’ worth of code written on it so far. A little bit more of the Windows and Mac sides had been started. The model was a big pile of back-end code and then as small as possible a piece of front-end code for each of the three platforms.

Seibel:And was this all new code?

Zawinski:It was all new code. Most of the Netscape founders had been NCSA/Mosaic developers so they had written the various versions of NCSA/Mosaic, which was actually three different programs. And all six of those people were at Netscape. They weren’t reusing any code but they had written this program before.

Seibel:So they started with an empty disk and started typing?

Zawinski:Exactly. I never looked at the Mosaic code; still haven’t. We actually were sued over that at one point; the university claimed that we were reusing their code and I guess that was settled one way or the other. There’s always been that rumor that we started that way, but we didn’t.

And really, why would we? Everyone wants to write version two, right? You were figuring it out while you wrote it and now you’ve got a chance to throw that away and start over—of course you’re going to start over. It’s going to be better this time. And it was. With the design that the other ones had, there was basically no way to load images in parallel, things like that. And that was really important. So we had a better design for the back end.

Seibel:Yet that’s also a classic opportunity to fall into the secondsystem syndrome.

Zawinski:It is, it is.

Seibel:How did you guys avoid that?

Zawinski:We were so focused on deadline it was like religion. We were shipping a finished product in six months or we were going to die trying.

Seibel:How did you come up with that deadline?

Zawinski:Well, we looked around at the rest of the world and decided, if we’re not done in six months, someone’s going to beat us to it so we’re going to be done in six months.

Seibel:Given that you picked the date first, you had to rein in scope or quality. How did that work?

Zawinski:We spent a long time talking about features. Well, not a long time, but it seemed like a long time because we were living a week every day. We stripped features, definitely. We had a whiteboard; we scribbled ideas; we crossed them out. This was a group of like six or seven people. I don’t remember exactly the number. A bunch of smart, egotistical people sitting in a room yelling at each other for a week or so.

Seibel:Six or seven being the whole Netscape development team or the Unix development team?

Zawinski:That was the whole client team. There were also the server folks who were implementing their fork of Apache, basically. We didn’t talk to them much because we were busy. We had lunch with them, but that was it. So we figured out what we wanted to be in the thing and we divided up the work so that there were, I guess, no more than two people working on any part of the project. I was doing the Unix side and Lou Montulli did most of back-end network stuff. And Eric Bina was doing layout and Jon Mittelhauser and Chris Houck were doing the Windows front end and Aleks Totić and Mark Lanett were doing the Mac front end for the pre–version 1.0 team. Those teams grew a little bit after that. But we’d have our meetings and then go back to our cubicles and be heads-down for 16 hours trying to make something work.

It was really a great environment. I really enjoyed it. Because everyone was so sure they were right, we fought constantly but it allowed us to communicate fast. Someone would lean over your cubicle and say, “What the fuck did you check in; that’s complete bullshit—you can’t do it that way. You’re an idiot.” And you’d say, “Fuck off!” and go look at it and fix it and check it in. We were very abrasive but we communicated fast because you didn’t have to go blow sunshine up someone’s ass and explain to them what you thought was wrong—you could say, “Hey, that’s a load of shit! I can’t use that.” And you’d hash it out very quickly. It was stressful but we got it done pretty quickly.

Seibel:Are the long hours and the intensity required to produce software quickly?

Zawinski:It’s certainly not healthy. I know we did it that way and it worked. So the way to answer that question is, is there another example of someone delivering a big piece of software that fast that’s of reasonable quality where they actually had dinner at home and slept during the night? Has that ever happened? I don’t actually know. Maybe it has.

But it’s not always about getting it done as quickly as possible. It also would be nice to not burn out after two years and be able to continue doing your job for ten. Which is not going to happen if you’re working 80-plus hours a week.