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

And when your background, your entire background, is writing code where multiplatform means both Windows 3.1 and Windows 95, you have no concept how big a deal that is. So it made the Unix side of things—which thankfully was no longer my problem—a disaster. It made the Mac side of things a disaster. It meant it was no longer possible to ship on low-end Windows boxes like Win16. We had to start cutting platforms out. Maybe it was time to do that, but it was a bad reason. It was unnecessary.

It really felt—this is my bitter, selfish way of looking at it—like Terry and I built this great thing and were punished for our success by having it handed over to idiots. That was a very unhappy time for me at Netscape. That began the period where I was only there waiting to vest.

Seibel:So you lasted there five years?

Zawinski:Yeah. A year past vesting, because just before vesting day mozilla.org started and that was really interesting again, so I stuck around for that.

Seibel:Did you ultimately get dragged into using C++?

Zawinski:Well, there was the Java thing. At one point, we were going to rewrite the browser in Java. We were like, “Yes! We’re going to get to ditch that 4.0 code base which is going to destroy our company and this is gonna actually work because, like, we know what we’re doing!”

And it didn’t work.

Seibel:Did it just not work because Java wasn’t ready?

Zawinski:No. We were all broken up into fairly well-defined groups again. There were three of us working on the mail reader. And we were done. We had a really nice mail reader that was fast and had a lot of really nice features and was better about saving your data—there were never any stalls where it was writing some big file. We took really good advantage of multithreading in Java, which was less painful than I had expected it to be. It was just really pleasant to work on. From the API we had designed we saw all these directions it could grow.

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.

Seibel: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.”

Seibel: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.

Seibel: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.

Seibel: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.

Seibel: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.

Seibel: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.

Seibel: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.

Seibel: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?