O que a Lei de Jamie Zawinski significa?

Preciso de uma explicação adequada da Lei do Envelope de Software de Jamie Zawinski :

Todo programa tenta expandir até poder ler mensagens. Os programas que não podem ser expandidos são substituídos por outros que podem.

Todas as respostas (e comentários) até agora parecem se concentrar inteiramente na primeira metade da declaração, transformando-a em um comentário sobre "inchaço", quando a metade importante é a segunda metade: os programas que não podem ser expandidos são substituídos por outros que pode.

Não se trata de inchaço de software, é sobre as realidades do mercado. As pessoas podem dizer que desejam um produto simples, mas quando você analisa o uso real, as coisas que são usadas são aquelas que permitem que os usuários façam mais e acabam substituindo ferramentas menos capazes.

Parte do problema é que "simples" é uma palavra confusa. Como "cortar", pode significar duas coisas quase completamente opostas. O que as pessoas querem é algo que simplifique tarefas complexas. Esse é "o bom simples" e requer muita complexidade para fazer o certo. No entanto, o que algumas pessoas interpretam é que as pessoas querem algo simplista ou minimalista. Esse conceito pode ter algum apelo de nicho, mas, no geral, é o tipo errado de "simples" para focar ao projetar um produto. Não importa o quão bom é o seu trabalho, as novas solicitações de recursos continuam chegando.

Para dar um exemplo, há o programa em que trabalho no trabalho. Você provavelmente nunca ouviu falar, mas somos líderes de mercado em um setor especializado: controle de mídia. É provável que nosso programa execute sua TV e / ou estação de rádio favorita. Os clientes adoram, eles dizem que é por isso muito melhor do que qualquer outra coisa que já trabalhou com.

Também é enorme . O EXE tem mais de 65 MB de tamanho, com cerca de 4 milhões de linhas de código, apoiadas por um banco de dados com mais de 150 tabelas, criadas ao longo de mais de uma década de trabalho. E, no entanto, parece que toda vez que tentamos instalá-lo em alguma nova estação ou rede, há uma ou duas coisas que são absolutamente essenciais para o fluxo de trabalho, das quais não temos suporte. Então, acabamos adicionando os novos recursos porque, caso contrário, os clientes não gostariam de mudar do sistema ao qual já estão acostumados. E deixe-me repetir, os clientes adoram.

Você precisa entender que isso aconteceu há muito tempo e, naquela época, ainda não era comum os computadores poderem executar mais de um programa por vez para um determinado usuário. DOS para computadores pessoais (e possivelmente o Windows 3 na parte superior) e terminais baseados em caracteres para usuários do Unix (apenas alguns tinham o X11).

Isso significa que, para verificar se você recebeu um e-mail, teve que sair do que estava fazendo no momento, inicie o programa de email, leia-o, saia do programa de email e reinicie o programa antigo. Eu acho que você pode ver que, se seu programa atual permitir que você leia seu e-mail, você poderá evitar tudo isso.

Portanto, se o seu programa atual não pôde ler seu email, você estava inclinado a fazê-lo (lembre-se de que eram alunos do MIT) ou a mudar para outro que pudesse.

Hoje em dia isso é difícil de imaginar, mas você pode ter uma idéia de como era se limitando a uma única janela do navegador - sem guias, sem janelas extras - e talvez até sem usar marcadores.

Como todo mundo já mencionou, a "lei" é uma observação bem-humorada sobre o inchaço do software e a fluência de pontuação , e é muito semelhante à décima regra de Greenspun :

Qualquer programa C ou Fortran suficientemente complicado contém uma implementação lenta ad hoc, especificada informalmente, cheia de bugs e com erros, de metade do Common Lisp.

A lei reflete o trabalho de Zawinski com o navegador Netscape e, mais tarde, com o Netscape Mail & News, conforme descrito aqui pelo próprio:

Em seguida, projetei e Terry Weissman e implementamos os clientes Netscape Mail and News, versões 2.0 a 3.0. Esta foi a nossa contribuição para a prova da Lei do Envelope de Software :

"Todo programa tenta se expandir até poder ler e-mails. Os programas que não podem ser expandidos são substituídos por outros que podem".

O navegador Netscape, na época o navegador mais popular, costuma ser criticado por ter muitos recursos para seu próprio bem, se não me engano horrivelmente, foi o último navegador (popular) que suportou dois mecanismos de renderização, Gecko e Trident. Por exemplo, Ben Goodger identifica o inchaço da Netscape como um dos (muitos) motivos que levam à criação do Firefox ¹ :

Disfunção da interface do usuário do Mozilla

Como a maior parte do design da interface do usuário para os produtos Netscape foi feito pela equipe da Netscape que trabalhava com os requisitos do Netcenter, a interface do usuário Mozilla sofreu. Em vez de ser um núcleo limpo sobre o qual a Netscape poderia criar um produto para atender às suas necessidades, o conjunto Mozilla nunca se sentiu bem; estava repleto de construções desajeitadas da interface do usuário que existiam apenas para serem preenchidas por sobreposições no repositório de fontes privadas do Netscape - a “árvore comercial”.

Para compor essa disfunção, no momento em que o projeto estava sendo desenvolvido por mais de cem engenheiros em diferentes departamentos, às vezes mal conectados no CPD. A Netscape havia crescido rapidamente nos anos anteriores e, com uma contratação desigual de engenheiros de barra com habilidades que sugerissem que eles precisavam de mais assistência de outras pessoas, tinha autonomia demais no design e na implementação de recursos. A assistência à experiência do usuário era escassa e, como resultado, o aplicativo rapidamente ficou inchado.

_{¹ De uma versão arquivada do agora extinto blog de Ben Goodger.}

Não é uma lei real , é um comentário satírico sobre como os projetos de software (se não forem gerenciados adequadamente) podem crescer tão grandes e complicados que, de alguma forma, acabam por incluir um leitor de e-mail (mesmo que não tenha nada a ver com o objetivo original do projeto) . Um gerente que eu já tive gostava de uma frase semelhante "Qualquer sistema suficientemente complicado contém uma implementação LISP meia-boca nele".

É um comentário sobre como alguns projetos de software parecem continuar expandindo e adicionando mais e mais recursos.

Muitos projetos parecem incapazes de resistir à adição de recursos, necessários ou não.

Uma conclusão lógica é que todo software acabará enviando correio.

Veja também Rastejamento do escopo .

Eu vejo pelo menos três maneiras de vê-lo.

Uma é ignorar a leitura de mensagens em si e ver como uma declaração de que as pessoas parecem gostar de produtos com a flexibilidade de se voltar para quase qualquer tarefa, independentemente do pouco que possa ter a ver com a intenção original da ferramenta. Se olharmos para ele dessa forma, um produto como o Photoshop que não leitura mail de suporte não é uma anomalia, pois sua arquitetura plug-in é bastante flexível que poderia suportar a leitura de email, mesmo que (tanto quanto eu sei) não esse plug-in existe. Esse ponto de vista pode ser resumido de maneira mais limpa, mas menos original, como "flexibilidade supera especialização".

A segunda maneira de ver isso é que Jamie Zawinski tem um foco tão estreito que simplesmente ignora produtos como Photoshop, PowerPoint, a maioria dos jogos, etc., que existem há anos, não suportam a leitura de mensagens e não parece estar sendo substituído por qualquer outra coisa que faça isso também.

O terceiro seria um contraponto ao segundo, dizendo que, em essência, a integração entre produtos ocorreu a tal ponto que efetivamente a leitura de mensagens é integrada a tudo porque a maioria das pessoas agora tem um leitor de mensagens em segundo plano, tudo o tempo e pode alternar para ele com rapidez e facilidade, cortar e colar com qualquer outra coisa etc., para que os pequenos detalhes de que o leitor de correio é empacotado como um aplicativo separado se tornem irrelevantes.