Meir "Manny" Lehman (1925–2010) foi um influente professor e chefe do Departamento de Computação do Imperial College London (1972–2002) e, posteriormente, professor na Universidade de Middlesex, sendo um pioneiro no campo da Engenharia de Software. Sua contribuição mais notável são as Leis de Lehman, um conjunto de oito princípios que descrevem a evolução, o comportamento e o ciclo de vida dos sistemas de software em larga escala, enfatizando a inevitabilidade de mudanças contínuas e o aumento da complexidade ao longo do tempo. Formuladas a partir de 1974, essas leis (como a "Mudança Contínua" e a "Complexidade Crescente") são amplamente utilizadas para entender como manter sistemas "evolutivos" (como sistemas bancários ou de controle de tráfego aéreo) relevantes, funcionais e adaptáveis, orientando práticas modernas como o desenvolvimento Ágil e o DevOps. Em seu artigo de 1980, Meir M. Lehman [1] delimitou o escopo de aplicação de um conjunto de leis relacionadas à evolução de software ao distinguir três categorias de software:

Um programa S (de "Specification") é desenvolvido a partir de uma especificação exata que define tudo o que ele deve fazer. Sua validade decorre inteiramente dessa especificação. Em geral, são programas estáticos, com pouca ou nenhuma necessidade de mudanças ao longo do tempo. Exemplos típicos são compiladores, algoritmos matemáticos ou módulos de software para cálculos fixos, em que toda operação e resultado são previstos pelo desenho inicial. Devido a essa característica, os programas do tipo S costumam ser distinguidos dos tipos P (problem-oriented) e E (embedded/real-world), que precisam evoluir continuamente para atender a novos requisitos e acompanhar as transformações do contexto real. Um programa P é criado para modelar um problema do mundo real. Embora também siga uma especificação, seu valor e sua validade são estabelecidos não apenas por ela, mas pela comparação entre sua saída e o próprio contexto real que busca representar. Programas do tipo P (P-Programs) são definidos como softwares projetados para resolver problemas do mundo real — como jogar xadrez, realizar previsões meteorológicas ou logística de vendas — onde uma solução exata é frequentemente inviável devido à complexidade computacional ou à presença de incertezas. Nesses casos, o software não pode seguir apenas uma especificação teórica rígida; ele precisa adotar aproximações e heurísticas para ser prático, criando um modelo que é, essencialmente, uma abstração da realidade sob a ótica do analista. A distinção crítica é que, diferentemente dos programas do tipo S (cuja qualidade é medida pela correção estrita em relação à especificação), a aceitação dos programas P é determinada pela sua validade e valor dentro do ambiente real. O sucesso é avaliado comparando-se os resultados gerados pelo software com os dados observados na realidade; discrepâncias entre a saída do computador e o mundo real forçam alterações na percepção do problema, no modelo adotado e, consequentemente, na implementação do sistema. Por fim, programas P estão fadados a sofrer alterações contínuas e intermináveis. Isso ocorre não apenas porque os modelos originais raramente são perfeitos ou porque a percepção humana sobre o problema muda, mas também porque o próprio ambiente real evolui. Sem essa adaptação constante, o programa torna-se progressivamente menos eficaz e perde seu valor econômico ou prático. Um programa E é projetado para mecanizar uma atividade humana ou social [1]. Por isso, está imerso na própria realidade que modela. Seu comportamento é fortemente influenciado pelo ambiente em que opera, exigindo adaptações contínuas às demandas e circunstâncias desse ambiente. Como qualquer software que acompanha mudanças ao longo do tempo, um programa E segue as Leis de Lehman, sendo sujeito a uma evolução incremental. Isso significa que, ao invés de mudanças disruptivas ou reescritas completas, o software tende a passar por ajustes progressivos e cuidadosos. Essa característica torna o programa E um sistema legado, cuja complexidade aumenta de forma gradual à medida que novas funcionalidades são integradas, como observado pela 2o Lei de Lehman ( a Lei da Complexidade Crescente). Conhecidos como programas extensíveis, os programas Tipo A das leis de Lehman são diretamente ligados e adaptados a aplicações do mundo real. Eles se distinguem dos sistemas "S" (estáticos) pela sua capacidade de evoluir continuamente com as necessidades dos usuários, combinando traços de sistemas "P" (programas) e "E" (executáveis).

Programas do tipo A (Application programs) São definidos como: A combinação dos programas P e E. Envolvem aplicações do mundo real e evoluem em função da mudança desse mundo. Portanto:

Tipo A = P + E Abrange qualquer software cujo valor depende de sua adequação ao ambiente real, seja ele um modelo (P) ou um sistema sociotécnico embutido (E).

As leis Ao todo, foram formuladas oito leis ao longo de mais de 20 anos de trabalho

Mudança Contínua — A Lei da Mudança Contínua afirma que todo sistema classificado como tipo E (Evolving System) — ou seja, sistemas que representam, suportam ou automatizam uma parte da realidade no mundo real — deve ser continuamente modificado para permanecer útil. Caso contrário, torna-se progressivamente menos satisfatório devido à evolução constante do domínio ao qual está acoplado. Um sistema tipo E reflete uma realidade externa dinâmica, como regras de negócio, leis, comportamentos sociais, mercado, tecnologia, infraestrutura e expectativas dos usuários. Essa realidade muda independentemente do software, enquanto o software não muda sozinho. Sem ação deliberada de evolução, ocorre um processo de obsolescência funcional, acúmulo de inconsistências e perda de adequação ao propósito original. Lehman descreve isso como um “envelhecimento” inevitável. Que é o processo em que o domínio muda, o modelo do sistema não acompanha e, assim, cresce a distância entre eles, reduzindo a utilidade do sistema. Isso explica por que sistemas como bancários, educacionais, ERPs, plataformas de marketing, sistemas fiscais, sistemas de logística, plataformas digitais corporativas, entre outros, requerem evolução contínua — novas regulações, práticas de mercado, integrações externas, expectativas de UX e requisitos de segurança surgem regularmente. A Lei da Mudança Contínua só se aplica a sistemas E, porque os Sistemas S não estão acoplados ao mundo real e os Sistemas P têm foco no problema, não no ambiente. Apenas sistemas E sofrem pressões sociotécnicas. Isso torna a mudança não opcional, mas inerente. Logo, não faz sentido estender essa lei a sistemas S ou P; o fenômeno não se manifesta nesses contextos. Complexidade Crescente — à medida que um sistema do tipo E evolui, sua complexidade aumenta, a menos que haja esforço específico para mantê-la ou reduzi-la. O conceito de Complexidade Crescente, proposto por Meir Lehman, é como reformar uma casa antiga. Quando um programa de computador (o "sistema") é lançado, ele é como uma casa recém-construída: as paredes, a fiação e o encanamento estão organizados. No entanto, o mundo real está sempre mudando, então o programa precisa de "reformas" (novos recursos, correções). A lei afirma que cada reforma ou "puxadinho" inevitavelmente torna a casa mais confusa por dentro. A cada novo remendo na fiação, por exemplo, o mapa original se perde, as conexões ficam mais enroladas e o risco de um curto-circuito (um bug) aumenta. Essa desorganização crescente é a complexidade que faz com que as próximas reformas sejam mais lentas, caras e difíceis de fazer. Essa complexidade, porém, não é um destino inevitável. Lehman explica que ela só aumenta "a menos que haja um esforço específico para mantê-la ou reduzi-la." Continuando a analogia da casa: se, ao fazer um "puxadinho", o dono não parar para reorganizar e limpar toda a fiação antiga, a bagunça se acumula. Esse "esforço específico" é o tempo que os desenvolvedores gastam para limpar o código, reescrever partes confusas e garantir que a arquitetura permaneça clara (o que chamamos de Refatoração). Sem esse investimento constante, o custo de simplesmente consertar um vazamento ou adicionar uma nova tomada (a manutenção) se torna tão grande que, eventualmente, a casa se torna insustentável e precisa ser demolida e reconstruída do zero. Autorregulação — A Lei Fundamental da Evolução de Programas postula que a evolução de um sistema de software não é regida exclusivamente por decisões gerenciais arbitrárias, mas obedece a uma dinâmica própria que torna o processo de programação um sistema autorregulável. Segundo esta lei, o processo de desenvolvimento e as métricas globais de um projeto (como taxa de crescimento e densidade de erros) apresentam tendências e invariantes estatisticamente determináveis. Embora decisões individuais de gerentes e programadores pareçam isoladas e independentes, sua agregação é moderada por múltiplos ciclos de feedback (organizacionais, técnicos e de uso). A lei sugere que grandes projetos de software funcionam como sistemas biológicos ou sociais complexos, onde mecanismos de estabilização atuam contra mudanças drásticas. Conforme o sistema envelhece, o controle local diminui e as características globais da evolução passam a ser determinadas pela dinâmica do "metassistema" (a interação entre a organização, o processo e o software existente). A existência dessa dinâmica implica que tentativas de forçar o desenvolvimento além dos limites naturais do sistema (como aumentar excessivamente o ritmo de trabalho em uma release) tendem a ser neutralizadas pelo próprio processo, resultando frequentemente em períodos subsequentes de baixa produtividade ou necessidade de correções (limpeza). Portanto, o planejamento de releases deve basear-se na extrapolação estatística do histórico do sistema, e não apenas em desejos de mercado ou intuição gerencial. Conservação da Estabilidade Organizacional — afirma que a taxa de desenvolvimento de um software tende a permanecer constante ao longo do tempo, mesmo com o aumento de recursos humanos. Isso ocorre porque sistemas grandes exigem maior esforço cognitivo: desenvolvedores têm dificuldade em compreender toda a complexidade do sistema, usuários enfrentam desafios para assimilar suas funcionalidades e organizações encontram barreiras para adaptar seus processos. O simples acréscimo de novos desenvolvedores não acelera proporcionalmente o progresso, pois aumenta a necessidade de comunicação, coordenação e treinamento, resultando no efeito descrito por Brooks. Assim, a produtividade depende menos da quantidade de pessoal e mais da eficiência dos processos, da comunicação e do uso de metodologias ágeis e práticas enxutas para lidar com a crescente complexidade dos sistemas. Conservação da Familiaridade — para que a evolução de um sistema do tipo E seja satisfatória, é essencial que todos os envolvidos mantenham domínio sobre seu conteúdo e comportamento. Crescimentos excessivos comprometem esse domínio; por isso, o incremento médio tende a permanecer relativamente constante ao longo da evolução. O processo não deve tornar o software irreconhecível para o usuário: suas características de usabilidade e sua cultura precisam ser preservadas. O objetivo é garantir que a complexidade das mudanças não ultrapasse a capacidade cognitiva da equipe de manutenção nem dos usuários de operação, evitando distorções funcionais e queda na qualidade. Crescimento Contínuo — o conteúdo funcional de um sistema do tipo E precisa ser ampliado continuamente para manter a satisfação do usuário ao longo do tempo. Isso significa que um sistema E em algum momento, por razões de tempo, recursos ou até mesmo de evolução da tecnologia, pode não atender todas as demandas dos usuários, e isso leva a necessidade da adição de recursos e funcionalidades para que o sistema siga sendo utilizado por usuários. Qualidade em Declínio — a qualidade de um software tende a diminuir com o tempo, a menos que a equipe faça manutenção contínua, como melhorias de código, refatorações, ajustes de desempenho e atualizações. À medida que o software cresce e se torna mais complexo, sua estrutura começa a se desgastar, o que causa perda de qualidade. Portanto, para manter o software bom e confiável, é preciso investir regularmente em práticas de engenharia que combatam essa deterioração. Sistema de Feedback — Processos evolutivos em sistemas do tipo E formam estruturas de feedback multinível, multiloop e multiagente. O tratamento adequado desses retornos cíclicos é condição essencial para obter melhorias significativas no software. O sucesso do sistema depende do reconhecimento de que as atividades de desenvolvimento são restringidas e impulsionadas por reações em cadeia: o comportamento do usuário muda com novas funcionalidades, a infraestrutura reage a novas cargas e a organização impõe novas restrições. Ignorar a natureza cíclica desses feedbacks resulta em estagnação e instabilidade a longo prazo.

Referências Lehman, Meir M. (1980). «Programs, Life Cycles, and Laws of Software Evolution». Proc. IEEE. 68 (9): 1060–1076. doi:10.1109/proc.1980.11805