Except the one thing that it couldn’t do was display messages. Because what it did was, it generated HTML and to display HTML you need an HTML display layer, which wasn’t done and was never finished. The layout group just completely went down a rat hole and they were the reason that that project got canceled.
Seibeclass="underline" So they were presumably wrestling with the—at that time—immature Java GUI technology.
Zawinski: I don’t think so. Because all the chrome worked. There was just this big blank rectangle in the middle of the window where we could only display plain text. They were being extremely academic about their project. They were trying to approach it from the DOM/DTD side of things. “Oh, well, what we need to do is add another abstraction layer here and have a delegate for this delegate for this delegate. And eventually a character will show up on the screen.”
Seibeclass="underline" Overengineering seems to be a pet peeve of yours.
Zawinski: Yeah. At the end of the day, ship the fucking thing! It’s great to rewrite your code and make it cleaner and by the third time it’ll actually be pretty. But that’s not the point—you’re not here to write code; you’re here to ship products.
Seibeclass="underline" Folks engaged in overengineering usually say, “Well, once I’ve got this framework in place everything will be easy after that. So I’ll actually save time by doing this.”
Zawinski: That is always the theory.
Seibeclass="underline" And there are times when that theory is true, when someone has good sense and the framework isn’t too elaborate, and it does save time. Is there any way you can tell which side of the line you’re on?
Zawinski: I know it’s kind of a cliché but it comes back to worse is better. If you spend the time to build the perfect framework that’s going to do what you want and that’s going to carry you from release 1.0 through release 5.0 and everything’s going to be great; well guess what: release 1.0 is going to take you three years to ship and your competitor is going to ship their 1.0 in six months and now you’re out of the game. You never shipped your 1.0 because someone else ate your lunch.
Your competitor’s six-month 1.0 has crap code and they’re going to have to rewrite it in two years but, guess what: they can rewrite it because you don’t have a job anymore.
Seibeclass="underline" There must have been times, perhaps on a shorter time frame, where you’ve ripped out a big chunk of code because you thought it would be faster to start over.
Zawinski: Yes, there are definitely times when you have to cut your losses. And this always feels wrong to me, but when you inherit code from someone else, sometimes it’s faster to write your own than to reuse theirs. Because it’s going to take a certain amount of time to understand their code and learn how to use it and understand it well enough to be able to debug it. Where if you started from scratch it would take less time. And it might only do 80 percent of what you need, but maybe that’s the 80 percent you actually need.
Seibeclass="underline" Isn’t it exactly this thing—someone comes along and says, “I can’t understand this stuff. I’ll just rewrite it”—that leads to the endless rewriting you bemoan in open-source development?
Zawinski: Yeah. But there’s also another aspect of that which is, efficiency aside, it’s just more fun to write your own code than to figure out someone else’s. So it’s easy to understand why that happens. But the whole Linux/GNOME side of things is straddling this line between someone’s hobby and a product. Is this a research project where we’re deciding what desktops should look like and we’re experimenting? Or are we competing with Macintosh? Which is it? Hard to do both.
But even phrasing it that way makes it sounds like there’s someone who’s actually in charge making that decision, which isn’t true at all. All of this stuff just sort of happens. And one of the things that happens is everything get rewritten all the time and nothing’s ever finished. If you’re one of those developers, that’s fine because there’s always something to play around with if your hobby is messing around with your computer rather than it being a means to an end—being a tool you use to get whatever you’re actually interested in done.
Seibeclass="underline" Speaking of messing around with a computer for its own sake, do you still enjoy programming?
Zawinski: Sometimes. I end up doing all the sysadmin crap, which I can’t stand—I’ve never liked it. I enjoy working on XScreenSaver because in some ways screen savers—the actual display modes rather than the XScreenSaver framework—are the perfect program because they almost always start from scratch and they do something pretty and there’s never a version 2.0. There’s very rarely a bug in a screen saver. It crashes—oh, there’s a divide-by-zero and you fix that.
But no one is ever going to ask for a new feature in a screen saver. “I wish it was more yellow.” You’re not going to get a bug report like that. It is what it is. So that’s why I’ve always written those for fun. They make this neat result and you don’t have to think about them too much. They don’t haunt you.
Seibeclass="underline" And do you enjoy the puzzle of doing some math and figuring out geometry and graphics?
Zawinski: Yeah. What’s this abstract little equation going to look like if I display it this way? Or, how can I make these blobs move around that looks more organic and less rigid, like a computer normally moves things? Stuff like that. What do I do to these sine waves to make it look more like something bouncing?
And then I end up writing all these stupid little shell scripts—selfdefense stuff. I know I could do this by clicking on 30,000 web pages and doing it by hand, but why don’t I write this script—little timesaver things. Which barely feels like programming to me. I know to people who aren’t programmers, that seems like a black art.
I really enjoyed doing the Mac port of the XScreenSaver framework. That was actually writing a lot of new code that required thinking about APIs and the structure of the thing.
Seibeclass="underline" Was that your APIs—how you were structuring your code?
Zawinski: Both. Both figuring out the existing APIs and figuring out the best way to build a layer between the X11 world and the Mac world. How should I structure that? Which of the Mac APIs is most appropriate? It was the first time in a long time that I’d done something like that and it was just like, “Wow, this is kind of fun. I think I might be kind of good at this.”
It had been forever because I got completely burned out on the software industry. That part of it I just couldn’t take anymore—the politics of it both in the corporate world and in the free-software world. I’d just had too much. I wanted to do something that didn’t involve arguing online about trivia. Or having my product destroyed by bureaucratic decisions that I had no input in.
Seibeclass="underline" Are you ever tempted to go back and hack on Mozilla?
Zawinski: Nah. I just don’t want to be arguing with people and having pissing matches in Bugzilla anymore. That’s not fun. That kind of thing is necessary to build big products. If it’s something that requires more than one person working on it, which obviously Mozilla does, that’s the way you have to do it. But I don’t look forward to that kind of fight anymore. That’s been beaten out of me by too many years of it. And the other alternative, as a programmer, is go work for someone else. And I don’t have to do that, so I can’t. My first bad day I’d just leave. And were I to start my own company I couldn’t be a programmer—I’d have to run the company.