What does Jamie Zawinski's Law mean?

Question

I need a proper explaination of Jamie Zawinski's Law of Software Envelopment:

Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.

Answer 1

All the answers (and comments) so far seem to focus entirely on the first half of the statement, making it into a comment about "bloat," when the important half is the second half: Those programs which cannot so expand are replaced by ones which can.

This is not about software bloat, it's about the realities of the market. People may say they want a simple product, but when you look at actual usage, the things that get used are the things that allow users to do more, and they end up replacing less-capable tools.

Part of the problem is that "simple" is a confusing word. Like "cleave," it can mean two almost completely opposite things. What people want is something that simplifies complex tasks. That's "the good simple," and it requires a great deal of complexity to do right. What some people interpret it as, though, is that people want something simplistic, or minimalist. This concept may have some niche appeal, but on the whole it's the wrong kind of "simple" to focus on when designing a product. No matter how good your work is, the new feature requests keep coming in.

To give an example, there's the program I work on at work. You've probably never heard of it, but we're the market leader in a specialized industry: media control. Our program most likely runs your favorite TV and/or radio station. The customers love it, they say it's so much better than anything else they've worked with.

It's also enormous. The EXE is over 65 MB in size, with around 4 million lines of code, backed by a database with over 150 tables, built up over the course of more than a decade of work. And yet it seems like every time we try to get it installed at some new station or network, there's one or two things that are absolutely essential to their workflow, that we don't have any support for. So we end up adding the new features because otherwise the customers wouldn't want to switch from the system they're already used to. And let me repeat, the customers love it.

Answer 2

You have to understand that this happened a long while back, and at that time it was not yet mainstream for computers to be able to run more than one program at a time for a given user. DOS for Personal Computers (and possibly Windows 3 on top) and character based terminals for Unix-users (only a few had X11).

This mean that in order to check whether you had gotten an email you had to exit what you were currently doing, start the mail program, read mail, exit the mail program and restart your old program. I guess you can see that if your current program could let you read your email, you could avoid all that.

Hence if your current program could not read your email, you were inclined to either make it do so (remember this was MIT students) or switch to another which could.

These days that is hard to imagine, but you can get an inkling of how it was by limiting yourself to a single browser window - no tabs, no extra windows - and perhaps even not use bookmarks.

Answer 3

As everyone else already mentioned the "law" is a humorous observation on software bloat and score creep, and it's very similar to Greenspun's tenth rule:

Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

The law reflects Zawinski's work with the Netscape browser and later with Netscape Mail & News, as described here by, well, himself:

Next, I designed, and Terry Weissman and I implemented, the Netscape Mail and News clients, versions 2.0 through 3.0. This was our contribution to the proof of the Law of Software Envelopment:

"Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can."

Netscape browser, at the time the most popular browser, has often been criticised as having too many features for its own good, if I'm not horribly mistaken it was the last (popular) browser that supported two rendering engines, Gecko and Trident. For example, Ben Goodger identifies Netscape's bloat as one of the (many) reasons that lead to the creation of Firefox¹:

Mozilla's UI Dysfunction

Since most of the user interface design for the Netscape products was done by Netscape staff working to Netcenter requirements, the Mozilla user interface suffered. Instead of being a clean core upon which Netscape could build a product to suit its needs, the Mozilla suite never felt quite right; it was replete with awkward UI constructs that existed only to be filled in by overlays in the Netscape's private source repository — the “commercial tree.”

Compounding this dysfunction, at the time the project was being developed by over a hundred engineers in different, sometimes poorly connected departments within CPD. Netscape had grown rapidly in previous years, and with an uneven hiring bar engineers with abilities that would suggest they needed more assistance from others had far too much autonomy in feature design and implementation. User experience assistance was sparse, and as a result the application quickly bloated.

_{¹ From an archived version of Ben Goodger's now defunct blog.}

Answer 4

It's not a real law, it's a satirical comment on how software projects (if not properly managed) can grow so large and complicated, they somehow eventually include an email reader (even if it has nothing to do with the original purpose of the project). A manager I once had was fond of a similar phrase "Any sufficiently complicated system contains a half-assed LISP implementation within it".

Answer 5

It is a comment on how some software projects seem to keep expanding and adding more and more features.

Many projects can't seem to be able to resist adding features, whether needed or not.

A logical conclusion is that every piece of software will end up sending mail.

Also see Scope Creep.

Answer 6

I see at least three ways to view it.

One is to ignore mail reading per se, and view it as a statement that people seem to like products with the flexibility to be turned to almost any task, regardless of how little it might have to do with the tool's original intent. If we look at it this way, a product like Photoshop that doesn't support mail reading isn't an anomaly because its plug-in architecture is flexible enough that it could support mail reading, even though (as far as I know) no such plug-in exists. This viewpoint could be summarize more cleanly, but less originally, as "flexibility beats specialization".

The second way to view it would be that Jamie Zawinski has such a narrow focus that he simply ignores the products like Photoshop, PowerPoint, most games, etc., that have been around for years, don't support mail reading, and don't seem to be getting replaced by anything else that does either.

The third would be a bit of a counterpoint to the second, saying that, in essence, integration between products has happened to such a degree that effectively mail reading is integrated into everything because most people now have a mail reader running in the background, all the time and can switch to it quickly/easily enough, cut and paste with anything else, etc., that the minor detail that the mail reader is packaged as a separate application has become irrelevant.