As leis de Lehman sobre a evolução de software: por que o código apodrece em silêncio (e como reagir)

Software não quebra do jeito que pontes quebram. Uma ponte na qual ninguém nunca mexe ainda assim pode continuar de pé por cinquenta anos ou mais, e algumas resistem muito mais. Um código no qual ninguém nunca mexe faz o oposto: apodrece em silêncio. O mundo ao seu redor muda (sistemas operacionais se atualizam, APIs entram em desuso, regulamentações mudam, usuários esperam mais) e o programa intocado, congelado no tempo, fica um pouco menos útil a cada dia, até que numa manhã simplesmente para de funcionar.

Isso não é opinião. Está mais perto da física. Há mais de cinquenta anos, um pesquisador da IBM percebeu que grandes sistemas de software se comportam segundo padrões surpreendentemente consistentes à medida que envelhecem, e ele passou duas décadas transformando essas observações em um conjunto de leis empíricas hoje conhecidas como as leis de Lehman da evolução de software. Elas ainda descrevem o seu quadro de sprint hoje, quer você já tenha ouvido falar delas ou não.

Vamos conhecer as leis, de onde elas vieram, onde se sustentam, onde se quebram e, o mais importante, como usá-las em projetos reais neste trimestre.

Um estudo que fundou um campo por acidente

Meir "Manny" Lehman. Foto: Hilehman, CC BY-SA 4.0, via Wikimedia Commons.

No final da década de 1960, a IBM estava construindo o OS/360, um dos projetos de software mais ambiciosos de sua época. Meir “Manny” Lehman, junto com seu colega László Bélády, começou a estudar o histórico de releases daquele sistema, medindo como seu tamanho, sua contagem de defeitos e o esforço para alterá-lo evoluíam release após release. (Bélády e Lehman publicaram um modelo inicial disso no IBM Systems Journal em 1976.)

O que começou como três observações em 1974 cresceu para cinco em 1978 e, em 1996, para um conjunto de oito Leis da Evolução de Software. Lehman é hoje amplamente reconhecido como o pai de todo o campo de pesquisa da evolução de software: quando ele morreu, em 2010, a comunidade acadêmica o homenageou exatamente assim.

Uma sutileza importa antes de prosseguirmos, porque é justamente onde a maioria dos resumos superficiais escorrega. Lehman não afirmou que essas leis se aplicam a todo software. Ele classificou os programas em três tipos, a classificação SPE:

• Programas do tipo S são definidos inteiramente por uma eSpecificação fixa. Uma função que calcula um resultado matemático está correta ou incorreta em relação a essa especificação, ponto final. Ela nunca precisa mudar.
• Programas do tipo P resolvem um Problema do mundo real com uma solução aproximada (pense em um motor de xadrez) em que o problema é estável, mas nossa solução sempre pode melhorar.
• Programas do tipo E estão Embutidos no mundo real. Eles mecanizam uma atividade humana ou de negócio e se tornam parte do mundo que modelam. Uma plataforma bancária, um checkout de e-commerce, um sistema de prontuários hospitalares. No instante em que entram em produção, mudam o ambiente, o que muda os requisitos, o que força o software a mudar de novo.

As oito leis descrevem sistemas do tipo E, e quase tudo o que você entrega para ganhar a vida é do tipo E. É por isso que essas leis soam tão pessoais.

As oito leis da evolução de software em um relance

As leis também não são oito fatos desconexos. Elas se reforçam mutuamente em uma única dinâmica que empurra o sistema rumo à decadência, e uma única contraforça que a contém:

Como as leis se acumulam: as arestas vermelhas empurram rumo à decadência, o caminho verde é o esforço deliberado que a contém.

Lei 1: Mudança contínua

“Um sistema do tipo E precisa ser continuamente adaptado, ou se torna progressivamente menos satisfatório.”

Esta é a fundação. O valor de um programa do tipo E não é fixo; é definido em relação a um ambiente em movimento. Mantenha o software parado e a distância entre o que ele faz e o que o mundo precisa se amplia por conta própria.

Cenário prático. Seu aplicativo de e-commerce integra com um gateway de pagamento. Você escreveu essa integração há dois anos e ela funcionou impecavelmente, ninguém mexeu nela. Então o gateway anuncia que vai deixar de oferecer suporte ao TLS 1.1 e mudar o formato da assinatura dos webhooks em 90 dias. Você não escreveu nenhum bug, e mesmo assim sua funcionalidade “concluída” agora é um cronômetro em contagem regressiva para uma queda em produção. A Mudança contínua significa que nenhum módulo está realmente concluído; ele só está concluído por ora. A resposta de engenharia é reservar orçamento para uma manutenção que você ainda nem consegue nomear e projetar pontos de integração (adaptadores, interfaces versionadas) de modo que “o mundo mudou” custe a você uma pequena alteração em vez de uma reescrita.

Lei 2: Complexidade crescente

“À medida que um sistema do tipo E evolui, sua complexidade aumenta, a menos que se realize trabalho explícito para mantê-la ou reduzi-la.”

Repare na formulação: a complexidade aumenta por padrão. É a entropia natural de um sistema sob mudança contínua. Cada funcionalidade adicionada na correria de um prazo, cada caso especial enxertado em um fluxo existente, cada “depois a gente limpa isso” eleva a desordem estrutural. Reduzir a complexidade é a única coisa que exige esforço deliberado, e esse esforço raramente está no roadmap.

Cenário prático. O checkout de uma startup começa como uma única função limpa. Marketing quer um caminho para código de promoção, então um if é adicionado. Depois um caminho de fatura B2B. Depois um caminho de vale-presente. Depois exceções regionais de imposto. Dezoito meses mais tarde, aquela função tem 600 linhas com 40 flags que interagem entre si, e cada alteração corre o risco de quebrar um caminho do qual ninguém se lembra. A Lei 2 diz que isso não foi uma falha de disciplina de um desenvolvedor ruim: é a trajetória esperada. A contramedida é tratar o refactoring como um item recorrente, não como um feito heroico isolado: um “orçamento de complexidade” permanente (digamos, 15% a 20% de cada sprint) gasto em extrair módulos, apagar ramificações mortas e manter a complexidade ciclomática sob controle. Fronteiras de microsserviços e costuras de arquitetura limpa são táticas, mas o ponto estratégico é mais simples: se você não gastar energia combatendo a complexidade, a complexidade vence. (É exatamente isso que o pensamento Lean chama de eliminar desperdício: a complexidade que não justifica mais sua existência é muda, e podá-la é trabalho de verdade, não custo acessório.)

Lei 3: Autorregulação

“Os processos de evolução de sistemas do tipo E são autorreguláveis, com a distribuição das medidas de produto e de processo próxima da normal.”

Esta é a lei mais frequentemente distorcida nos resumos (ela não é sobre “evolução de programas grandes”). Lehman observou que a evolução de um sistema se comporta como um organismo regulado. Medidas como tamanho de release e taxa de crescimento flutuam em torno de uma tendência estável, com os picos e quedas se cancelando aproximadamente. Force demais em um release e o sistema tende a compensar: um mecanismo de feedback o puxa de volta para sua taxa de longo prazo.

Cenário prático. Um gerente de produto, frustrado com o progresso constante, decreta um release bombástico: o triplo do escopo normal em um único trimestre. O time obedece. O resultado é previsível para quem conhece esta lei: a contagem de defeitos dispara, o release seguinte encolhe drasticamente enquanto o time absorve as consequências, e a média dos dois releases cai quase exatamente sobre a linha de tendência histórica. A lição prática é um presente para quem planeja: o seu próprio histórico de releases é uma ferramenta de previsão. Se seus últimos dez releases tiveram em média ~30 story points de funcionalidade nova líquida com um padrão de chegada de defeitos aproximadamente normal, um plano que assume 90 está lutando contra a gravidade. Use a tendência para definir expectativas críveis e trate um release que a excede absurdamente como um sinal de risco, não como um triunfo.

Lei 4: Conservação da estabilidade organizacional

“A taxa média efetiva de atividade global em um sistema do tipo E em evolução é invariante ao longo da vida do produto.”

A taxa efetiva com que mudanças úteis são entregues tende a permanecer aproximadamente constante ao longo da vida de um projeto e, surpreendentemente, é em grande parte independente dos recursos que você joga no problema. Esta é a lei que se sobrepõe à famosa observação de Fred Brooks em The Mythical Man-Month de que “adicionar pessoas a um projeto de software atrasado o atrasa ainda mais”.

Cenário prático. Um projeto está três meses atrasado. O instinto da liderança é adicionar cinco engenheiros. Mas os novos contratados precisam aprender o domínio, o time existente precisa parar de construir para integrá-los, e o número de caminhos de comunicação no time cresce quadraticamente (um time de 5 pessoas tem 10 ligações entre pares; um time de 10 pessoas tem 45). Nos dois meses seguintes, a produção efetiva cai. A Conservação da estabilidade organizacional diz que a vazão é regida menos pelo número de pessoas do que pela complexidade acumulada do sistema e pela estrutura de comunicação da organização. A alavancagem não está em mais pessoas, está em remover atrito: reduzir tempos de build e deploy, pagar a complexidade da Lei 2, esclarecer responsabilidades e encurtar a latência do feedback para que a taxa efetiva de cada engenheiro suba.

Lei 5: Conservação da familiaridade

“À medida que um sistema do tipo E evolui, todos os envolvidos com ele (desenvolvedores, pessoal de vendas, usuários) precisam manter o domínio de seu conteúdo e comportamento para alcançar uma evolução satisfatória. O crescimento excessivo diminui esse domínio. Portanto, o crescimento incremental médio permanece invariante à medida que o sistema evolui.”

Todos os ligados ao sistema (desenvolvedores, operadores, pessoal de suporte e usuários) só conseguem absorver uma certa quantidade de mudança por release antes de perderem a noção de como ele funciona. Releases que empacotam novidade demais excedem esse orçamento de absorção, e a qualidade e a adoção sofrem com isso.

Cenário prático. Um time tenta uma reescrita “big bang”: um ano de trabalho, depois um único release que substitui 70% do produto de uma só vez. No lançamento, os tickets de suporte explodem, o time não consegue raciocinar sobre qual das mil mudanças causou qual regressão, e os usuários avançados se revoltam contra uma interface que não reconhecem mais. A Lei 5 explica os redesigns de UI fracassados de que todos nos lembramos: aqueles em que os usuários começaram abaixo-assinados para trazer de volta a versão antiga. A disciplina que ela prescreve é limitar a novidade de cada release, não apenas seu tamanho. Entregue continuamente em incrementos digeríveis, rode os caminhos novos e antigos lado a lado atrás de flags, e dê às pessoas tempo para construir familiaridade. A mudança que seu time e seus clientes conseguem entender é a restrição real, não a mudança que você consegue codificar.

Lei 6: Crescimento contínuo

“O conteúdo funcional de um sistema do tipo E precisa ser continuamente aumentado para manter a satisfação do usuário ao longo de sua vida.”

Aqui está o trio mais confundido de todo o conjunto, então vamos separá-los com clareza. A Lei 1 (Mudança) é sobre adaptar a funcionalidade existente a um mundo em transformação. A Lei 2 (Complexidade) é sobre a desordem interna que se acumula. A Lei 6 (Crescimento) é sobre a superfície externa de funcionalidades precisar se expandir porque as expectativas dos usuários só sobem e nunca recuam. O extra encantador de ontem é a suposição básica de hoje.

Cenário prático. Um produto SaaS de analytics é lançado com cinco integrações e os clientes adoram. Dois anos depois, prospects desistem em calls de vendas porque falta o conector do Snowflake que um concorrente adicionou no mês passado. O produto não ficou pior: seu conteúdo funcional simplesmente parou de crescer enquanto as expectativas continuaram subindo, e a diferença é lida como declínio. A Lei 6 é o motor por trás de todo roadmap de produto e de toda lista de funcionalidades “indispensáveis”. A pegadinha estratégica é que o Crescimento (Lei 6) e a Complexidade (Lei 2) puxam em direções opostas: cada funcionalidade que você adiciona para satisfazer os usuários também aumenta a entropia. Times maduros tratam isso como um trade-off explícito, podando funcionalidades de baixo valor com a mesma agressividade com que adicionam as de alto valor, para que o crescimento não hipoteque o código em silêncio.

Lei 7: Qualidade em declínio

“A qualidade de um sistema do tipo E parecerá estar declinando, a menos que seja rigorosamente mantida e adaptada às mudanças do ambiente operacional.”

Note a palavra precisa: a qualidade parecerá declinar. O código em disco não mudou, mas os padrões contra os quais ele é avaliado mudaram. O ambiente se moveu (novos navegadores, novos dispositivos, dez vezes mais tráfego, novas expectativas de segurança) e um programa que era excelente em relação à régua de 2019 parece capenga em relação à de 2026.

Cenário prático. Um monólito roda de forma confiável há anos. Ninguém introduziu um bug. Mesmo assim, os usuários agora reclamam que ele está “lento e travado”. O que de fato aconteceu: o tráfego mobile foi de 20% para 70% e o app nunca foi projetado para isso; o conjunto de dados cresceu 50× e consultas que eram instantâneas agora se arrastam; concorrentes estabeleceram um novo patamar de responsividade. A Qualidade em declínio diz que o antídoto é ativo, não reativo: você precisa se adaptar continuamente ao ambiente operacional, não apenas corrigir defeitos reportados. Na prática, isso significa observabilidade que acompanha o desempenho real em relação às expectativas de hoje, recalibração regular de carga e segurança, além de testes automatizados e pipelines de CI/CD que tornem a adaptação contínua barata o suficiente para de fato ser feita. Qualidade não é um estado que você alcança; é uma taxa que você sustenta.

Lei 8: Sistema de feedback

“Os processos de evolução de sistemas do tipo E constituem sistemas de feedback multinível, com múltiplos laços e múltiplos agentes.”

Esta é a chave de abóbada, e ela ressignifica todas as outras. Evoluir um sistema grande não é um pipeline linear do requisito ao código. É uma teia de laços de feedback: usuários reagem aos releases, dados de suporte fluem para o produto, decisões de produto restringem a engenharia, a realidade da engenharia remodela o roadmap, a estrutura organizacional molda a arquitetura (a Lei de Conway rondando por perto). Como os laços interagem, mudanças locais produzem efeitos não locais, muitas vezes contraintuitivos.

O laço externo de entrega mais os laços internos de correção tracejados: você conduz todos eles ao mesmo tempo, nunca um isoladamente.

Cenário prático. Um VP, na esperança de elevar a qualidade, decreta uma nova regra: todo pull request precisa de três aprovações. O laço pretendido diz “mais revisão → menos bugs”. O sistema real diz o contrário: as filas de revisão se acumulam, os engenheiros juntam PRs maiores para amortizar a sobrecarga, PRs grandes são aprovados sem critério porque ninguém consegue revisar 2.000 linhas com cuidado, e as taxas de defeito sobem. A Lei 8 alerta que você não consegue conduzir um sistema de feedback de forma confiável ajustando uma única variável e supondo que o resto fica parado. A disciplina que ela exige é humildade somada à medição: mude uma coisa, instrumente os laços, observe os efeitos de segunda ordem e ajuste: exatamente a postura empírica, orientada a hipóteses, que boas culturas de DevOps e de melhoria contínua codificam.

Onde as leis se dobram, e por que essa é a parte mais útil

Uma teoria de 50 anos construída sobre um mainframe dos anos 1960 merece escrutínio, e recebeu bastante. O desafio mais importante veio do open source.

Em 2000, Michael Godfrey e Qiang Tu estudaram o kernel Linux ao longo de 96 releases de 1994 a 2000 e encontraram algo que as leis não previam: o kernel cresceu a uma taxa superlinear. Isso contradizia diretamente o modelo de crescimento do inverso do quadrado que Lehman e Turski haviam derivado de sistemas comerciais, em que se esperava que o crescimento desacelerasse à medida que tamanho e complexidade tornassem cada alteração mais difícil. Um modelo de desenvolvimento massivamente paralelo, globalmente distribuído e voluntário aparentemente reescreveu a curva de crescimento. Estudos posteriores de open source de longa vida descobriram que as leis valem de forma irregular: a Mudança contínua se mostra notavelmente robusta, mas outras (a Conservação da familiaridade e a própria dinâmica de crescimento prevista) muitas vezes deixam de valer quando o contexto de um projeto muda (por exemplo, quando ele entra em fase de manutenção ou cresce por meio de contribuição massivamente paralela).

Por que as leis se dobram exatamente aqui? O desvio não é aleatório: ele se resume a muitos fatores, e o primeiro deles é que as forças que impulsionam o crescimento de funcionalidades não são as mesmas. Lehman derivou suas leis de sistemas comerciais, em que o que é construído é, em última instância, regido pelo mercado: funcionalidades são adicionadas para ganhar negócios, reter clientes e proteger a receita, e essa pressão econômica molda a cadência de releases, o escopo e o constante cabo de guerra entre nova funcionalidade e estabilidade. Um kernel open source responde a um conjunto completamente diferente de incentivos. Uma funcionalidade entra no Linux porque um contribuidor precisa dela para o próprio hardware, porque um fornecedor envia um driver para o upstream, porque os mantenedores a julgam tecnicamente sólida e digna do ônus de manutenção de longo prazo, e não porque ela mexe em um número de receita ou aparece em um roadmap de vendas. Não há trimestre a bater, não há métrica de churn, não há faixa de preço a proteger. E com milhares de contribuidores independentes, cada um resolvendo a própria necessidade em paralelo, o crescimento não é limitado pela capacidade de uma única organização (Lei 4) nem por aquilo com que um único time consegue se manter familiarizado (Lei 5), então ele pode correr de forma superlinear de um jeito que os conjuntos de dados comerciais de Lehman nunca mostraram. Os critérios que decidem se uma funcionalidade sequer existe são simplesmente diferentes dos critérios comerciais para os quais as leis foram calibradas.

Isso ressignifica todo o resultado. Várias das leis de Lehman são, no fundo, afirmações sobre a organização que produz o software (sua economia, sua capacidade, seus incentivos) tanto quanto sobre o código em si. Mude o motor que impulsiona o trabalho e o comportamento mensurável muda junto. O kernel Linux não quebrou as leis; ele funcionou com um motor diferente daquele que Lehman observou.

Isso não é razão para descartar as leis. É a razão para respeitá-las. As leis de Lehman são generalizações empíricas sobre um regime específico: sistemas fechados, desenvolvidos comercialmente, limitados organizacionalmente. Quando você muda o regime de forma fundamental (a economia, o paralelismo, o modelo de contribuição), algumas leis se dobram e outras estalam. Saber quais leis são robustas (a mudança é inevitável, a complexidade aumenta sem esforço, o feedback domina) e quais são condicionais (a curva exata de crescimento, a cadência autorreguladora) é exatamente o tipo de discernimento que separa os engenheiros que citam princípios dos engenheiros que os usam.

A única ideia para guardar

Tire a formalidade e as oito leis se reduzem a uma única e incômoda verdade:

Deixado por conta própria, ele se desalinha do mundo (Lei 1), acumula desordem interna (Lei 2), parece pior diante de padrões cada vez mais altos (Lei 7) e priva seus usuários do crescimento que eles agora esperam (Lei 6), enquanto laços de feedback que você não controla totalmente (Lei 8) resistem às suas tentativas de gerenciá-lo, e contratar mais gente não resolve o problema (Lei 4).

Os times que prosperam não são os que escapam dessas forças, ninguém escapa. São os que se planejam para elas: que reservam orçamento para manutenção antes que ela seja urgente, que gastam esforço contínuo combatendo a complexidade, que dimensionam cada release ao que as pessoas conseguem absorver, que tratam a qualidade como uma taxa sustentada em vez de uma linha de chegada, e que conduzem seu processo medindo seus laços em vez de emitir decretos dentro deles.

Existe um nome para essa postura. Se as leis de Lehman descrevem a doença (entropia que se acumula, complexidade que cresce sozinha, qualidade que escorrega à medida que o mundo segue em movimento), então o pensamento Lean é a coisa mais próxima de um tratamento que temos: remover desperdício (muda) implacavelmente, manter os lotes pequenos para que as pessoas nunca percam a noção do sistema (que é precisamente a Conservação da familiaridade de Lehman), construir qualidade desde a origem em vez de inspecioná-la depois, e deixar que laços de feedback, e não decretos, conduzam o trabalho (a Oitava Lei de Lehman, reformulada como prática de gestão). Não é uma analogia forçada: os dois frameworks descrevem o mesmo sistema a partir de extremos opostos, um nomeia as forças, o outro a disciplina que as responde.

O companheiro deste artigo

Lean Thinking for Busy Software Developers

As leis de Lehman nomeiam as forças que arrastam todo código rumo à decadência. Este livro é o manual de campo para reagir. Ele leva os princípios Lean da Toyota para o código: corte o desperdício invisível no seu processo, mantenha os lotes pequenos (a Conservação da familiaridade na prática), construa qualidade desde a origem em vez de inspecioná-la depois, e conduza com laços de feedback em vez de decretos, tudo com exemplos concretos, métricas DORA e um capítulo inteiro sobre trabalhar com agentes de IA.

Comprar na Leanpub → Saiba mais

Atualmente disponível em italiano; uma edição em inglês está em andamento, cadastre-se na Leanpub para ser notificado.

Lehman assistiu a um sistema operacional de mainframe lhe ensinar essas lições na década de 1970. Seu código distribuído, cloud-native e assistido por IA está ensinando-as de novo agora mesmo. A única pergunta é se você está lendo a ementa ou sendo avaliado em uma prova que nem sabia que estava fazendo.

Principais conclusões

• A decadência é o padrão. Um sistema do mundo real (do tipo E) deixado intocado não fica parado: ele se desalinha de seu ambiente (Lei 1) e parece perder qualidade (Lei 7).
• A complexidade cresce, a menos que você a combata. A Complexidade crescente (Lei 2) é entropia; só o refactoring deliberado a reverte. Reserve orçamento para isso, não fique na esperança.
• Mais gente não resolve o problema. A Conservação da estabilidade organizacional (Lei 4), bem como a Lei de Brooks, significam que a vazão é regida pela complexidade e pela comunicação, não pelo número bruto de pessoas.
• Entregue mudança que as pessoas consigam absorver. A Conservação da familiaridade (Lei 5) limita quanta novidade um time e seus usuários conseguem suportar por release. Lotes pequenos vencem reescritas big-bang.
• Continue crescendo, mas faça a poda. O Crescimento contínuo (Lei 6) é obrigatório para a satisfação, mas cada funcionalidade aumenta a complexidade: trate isso como um trade-off explícito.
• Conduza os laços, não as variáveis. A evolução é um sistema de feedback (Lei 8); mude uma coisa, meça os efeitos de segunda ordem e ajuste.
• As leis se dobram, então use discernimento. Elas valem de forma irregular em projetos modernos e open source: saiba quais são robustas e quais são condicionais.

Perguntas frequentes

O que são as leis de Lehman da evolução de software?

São oito observações empíricas, formuladas por Meir M. Lehman entre 1974 e 1996, que descrevem como sistemas de software do tipo E (aqueles embutidos no mundo real) inevitavelmente mudam, crescem e se degradam com o tempo, a menos que se invista esforço deliberado. O conjunto abrange Mudança contínua, Complexidade crescente, Autorregulação, Conservação da estabilidade organizacional, Conservação da familiaridade, Crescimento contínuo, Qualidade em declínio e Sistema de feedback.

O que é um sistema do tipo E?

Na classificação SPE de Lehman, um programa do tipo E é aquele embutido no mundo real que mecaniza uma atividade humana ou de negócio, como uma plataforma bancária ou um checkout de e-commerce. Diferentemente dos programas do tipo S (definidos por uma especificação fixa) e dos programas do tipo P (uma solução aproximada para um problema estável), um sistema do tipo E altera o próprio ambiente que modela, o que o força a evoluir continuamente. As oito leis descrevem sistemas do tipo E.

As leis de Lehman ainda valem para software moderno e open source?

Em parte. Estudos de replicação descobriram que as leis valem de forma irregular. A Mudança contínua é notavelmente robusta, mas outras se dobram assim que o regime de desenvolvimento muda. O estudo de Godfrey e Tu, de 2000, sobre o kernel Linux encontrou um crescimento superlinear que contradizia o modelo de crescimento do inverso do quadrado que Lehman derivou de sistemas comerciais, e estudos posteriores de FLOSS descobriram que leis como a Conservação da familiaridade muitas vezes deixam de valer.

Por que a qualidade do software parece declinar mesmo quando ninguém mexe no código?

Por causa da Sétima Lei de Lehman, a Qualidade em declínio: a qualidade de um sistema do tipo E é avaliada em relação a um ambiente em movimento. À medida que navegadores, dispositivos, volumes de tráfego e expectativas dos usuários avançam, o software intocado parece progressivamente pior, ainda que seu código nunca tenha mudado. O antídoto é a adaptação contínua ao ambiente operacional, não apenas a correção reativa de bugs.

Por que o kernel Linux não segue a lei de crescimento de Lehman?

Porque o kernel funciona sob incentivos diferentes dos sistemas comerciais que Lehman estudou. Seu modelo de crescimento pressupunha que o crescimento de funcionalidades é regido pela pressão de mercado e de receita dentro de uma única organização de capacidade limitada. No open source, funcionalidades são adicionadas porque os contribuidores precisam delas para seu próprio hardware, porque fornecedores enviam drivers para o upstream ou porque os mantenedores os julgam tecnicamente sólidos, e não para bater uma meta de receita ou um roadmap de vendas. Com milhares de contribuidores independentes trabalhando em paralelo, o crescimento não é limitado pela capacidade de uma única organização, então Godfrey e Tu (2000) mediram um crescimento superlinear em vez da desaceleração prevista. A lei não falhou; o kernel funciona com um motor diferente, porque os critérios que decidem se uma funcionalidade existe são diferentes dos critérios comerciais para os quais as leis foram calibradas.

Fontes e leituras adicionais: Bélády & Lehman, “A Model of Large Program Development,” IBM Systems Journal (1976); Lehman, “Laws of Software Evolution Revisited” (1996); Godfrey & Tu, “Evolution in Open Source Software: A Case Study” (2000); Canfora et al., “In memory of Manny Lehman, ‘Father of Software Evolution’” (2011); e González-Barahona et al., “Studying the laws of software evolution in a long-lived FLOSS project” (2014).