Teoria Que Já Existia
Todo defeito MOAD tinha uma solução conhecida décadas antes da detecção sistemática em 2026. Os defeitos não persistiram porque ninguém sabia melhor. Eles persistiram porque saber não é o mesmo que detectar.
MOAD-0001: list.contains O(N²)
Donald Knuth, 1973. The Art of Computer Programming, Volume 3: Sorting and Searching. Tabelas hash para busca O(1) totalmente especificadas, com análise, em 1973. A diferença entre busca linear O(N) e busca hash O(1) — documentada, formalizada, amplamente citada. Java lançou HashSet na versão 1.0 (1996). Python lançou set como tipo de primeira classe na versão 2.4 (2004). A correção existia há 30 anos antes de se tornar um idioma padrão em todo ecossistema.
Richard Hamming, 1986. Palestras da Bell Labs (publicadas posteriormente como The Art of Doing Science and Engineering, 1997). Hamming ensinou explicitamente complexidade algorítmica, a diferença entre correto e eficiente, e o perigo de construir sistemas que funcionam em pequena escala mas falham em grande escala. Ele chamou isso de "projetar para o problema que você consegue ver hoje, não para o problema que enfrentará amanhã."
MOAD-0002: Acoplamento por Estado Global Compartilhado
David Parnas, 1972. 'On the Criteria To Be Used in Decomposing Systems into Modules.' CACM, dezembro de 1972. Parnas argumentou que os módulos devem ser decompostos por ocultação de informação — cada módulo possui seu próprio estado, sem globais mutáveis compartilhados. Este é o predecessor teórico direto da correção Intertangle. Parnas foi explícito: estado global compartilhado cria acoplamento invisível que os testes não revelam.
MOAD-0003: Vazamento de Identidade ThreadLocal
Java 1.2, 1998. ThreadLocal foi incluído como classe da biblioteca padrão do Java. No momento em que pooling de threads e ThreadLocal coexistiram, o mecanismo do vazamento já existia. O defeito é estrutural: um portador cuja vida útil é a thread, não a unidade de trabalho. A documentação já alertava sobre isso desde o início do ciclo de vida do Java EE.
MOAD-0004: Credenciais Registradas em Log
RFC 1945, 1996. HTTP/1.0 definiu o cabeçalho Authorization. O defeito de registro de credenciais tornou-se possível no dia em que o cabeçalho Authorization existiu. A OWASP foi fundada em 2001 e documentou o registro de credenciais como uma classe de vulnerabilidade em seus primeiros guias. O padrão: cabeçalho Authorization → middleware de log → credenciais em texto claro no disco. Conhecível desde a primeira especificação de autenticação HTTP.
MOAD-0005: Thundering Herd / Cache Stampede
Núcleo Unix, 1993. O 'problema do rebanho trovejante' — N processos despertados simultaneamente em um evento compartilhado — apareceu em discussões de desenvolvimento do núcleo Unix no início dos anos 1990. O trabalho de Doug Schmidt sobre o padrão Reactor (1994) e Half-Sync/Half-Async (1995) abordou a sincronização no nível de infraestrutura. A variante de stampede de cache (N threads calculam o mesmo valor em um cache miss) foi documentada na literatura de sistemas distribuídos em 2001.
---
Teoria: completa. Ferramentas de detecção: ausentes. A lacuna entre 'conhecível' e 'detectado' varia de 28 a 54 anos, dependendo do defeito.
A Lacuna de Conhecimento
A linha do tempo mostra que todo defeito MOAD tinha uma solução conhecida pelo menos 28 anos antes da detecção sistemática. A menor lacuna (MOAD-0003) é de 28 anos. A maior (MOAD-0002) é de 54 anos.
Esta não é uma história sobre ignorância. Knuth, Parnas, Hamming — estes são os autores mais citados em ciência da computação. Seu trabalho foi adotado em universidades. Seu vocabulário (Big O, ocultação de informação, complexidade algorítmica) tornou-se currículo padrão.
Por que o Código Apodrece: Cinco Condições
Um defeito não persiste por acidente. Cinco condições estruturais, todas presentes simultaneamente, criam um ambiente de apodrecimento. Remova qualquer uma e a detecção se torna possível.
Condição 1: Saída Correta
Uma lista e um conjunto respondem à pergunta de pertinência de forma idêntica. list.contains(x) e set.contains(x) retornam o mesmo booleano. Um ThreadLocal que carrega uma identidade obsoleta ainda carrega uma identidade — ela simplesmente pertence à requisição errada. Credenciais registradas em log são registradas corretamente — a credencial chega ao arquivo de log sem erro. O defeito não é um mau funcionamento. É um mau funcionamento apenas em custo ou consequência de segurança. Testes que verificam saída passam. Testes que verificam custo ou consequência de segurança: em sua maioria, não escritos.
[BLOCK_TYPE five_conditions/conditions_diagram]
Condição 2: Sem testes de complexidade na CI
[BLOCK_TYPE five_conditions/conditions_diagram]Dijkstra disse: “testar mostra a presença de defeitos, não a sua ausência”. Hamming completou: os defeitos que testamos são os defeitos que encontramos. Pipelines de CI em 2026 testam: correção, segurança de tipos, contratos de API, comportamento funcional. Eles não testam: complexidade algorítmica por operação, crescimento de memória por chamada, remoção de cabeçalhos de autorização, ciclo de vida de identidade de thread. [BLOCK_TYPE five_conditions/conditions_diagram]
Nenhum teste é executado. Nenhum teste falha. O pipeline está verde. O defeito é invisível. [BLOCK_TYPE five_conditions/conditions_diagram]
Condição 3: Origem em N pequeno
[BLOCK_TYPE five_conditions/conditions_diagram]O código é escrito e revisado em ambientes de desenvolvimento. Gráficos de desenvolvimento têm 50 nós. Cargas de requisição em desenvolvimento têm 10 threads concorrentes. Taxas de cache miss em desenvolvimento são baixas (cache quente, poucas chaves). Em N=50 o custo O(N²) é 2.500 operações. Invisível. Em N=50.000 o custo é 2.500.000.000 operações. Um build de 17 minutos em vez de 1 segundo. [BLOCK_TYPE five_conditions/conditions_diagram]
O autor que escreveu o código nunca viu N=50.000. O revisor que aprovou nunca viu N=50.000. O defeito não era visível na escala em que foi escrito. [BLOCK_TYPE five_conditions/conditions_diagram]
Condição 4: Cópia propaga sem contexto
Um algoritmo correto é instrutivo. Tutoriais ensinam com exemplos corretos. A documentação mostra código funcional. O mesmo esqueleto de Tarjan SCC — visited = [], if n not in visited interno — aparece no GHC, Maven, Python pip, Cargo, TypeScript compiler, Kotlin compiler, Scala compiler e javac. Equipes diferentes, linguagens diferentes, décadas diferentes. Mesmo fóssil. O N=50 do autor original não se propaga com o código. O que se propaga: a saída correta. O que fica para trás: a suposição de desempenho.
Condição 5: A escala cresce em torno de código congelado
O código não degrada. A infraestrutura escala. Um resolvedor de dependências escrito em 2003 para 200 pacotes roda com 50.000 pacotes em 2024. Ninguém o reescreve — ele funciona. Ninguém o perfila — o CI está verde. O N que torna o custo O(N²) catastrófico chega gradualmente, de forma invisível, em escala de produção. Até lá, o autor original já saiu. O código é uma dependência. Ninguém toca em dependências que funcionam.
Diagnóstico: Cinco Condições
As cinco condições: saída correta, ausência de testes de complexidade, origem em N pequeno, cópia sem contexto, escala crescendo em torno de código congelado.
Todas as cinco estavam presentes em todo MOAD simultaneamente. Isso não é coincidência — é a assinatura estrutural de uma classe de defeitos sedimentares.
O que Hamming Disse
As palestras de Richard Hamming em 1986 nos Bell Labs — publicadas em 1997 como The Art of Doing Science and Engineering — contêm alertas que soam como descrições diretas do padrão de defeito MOAD. Ele não estava descrevendo MOAD. Ele descrevia a tendência estrutural dos sistemas de engenharia de se calcificarem em torno de decisões localmente corretas que se tornam globalmente caras.
Hamming sobre complexidade: 'O propósito da computação é insight, não números. Mas você precisa ter a complexidade certa do algoritmo ou os números nunca chegarão. Um algoritmo O(N²) que roda em N=100 não rodará em N=1.000.000 antes de você se aposentar.'
Hamming sobre cópia: 'Grandes engenheiros não apenas copiam soluções. Eles entendem por que a solução funciona, sob quais condições ela vale, e o que a quebraria. Uma solução copiada sem suas condições é uma bomba-relógio.'
Hamming sobre testes: 'Testar o que você mediu não é o mesmo que medir o que importa. Construímos suítes de testes elaboradas para as propriedades que escolhemos testar. Deixamos sem teste as propriedades que não escolhemos. O que deixamos sem teste é o que nos surpreende em produção.'
Hamming em escala: 'O erro que você comete no primeiro ano de um projeto é o erro que você ainda estará corrigindo no décimo ano. Suposições iniciais se calcificam. O projeto escala em torno delas. Ninguém reescreve a fundação.'
A Lacuna Entre o Alerta e a Operacionalização
Os alertas de Hamming estavam corretos. Foram ensinados. Foram citados. Foram incluídos em currículos. Mas um alerta não é um detector. Hamming descreveu a forma do defeito. Ele não construiu uma ferramenta que roda em CI e sinaliza caminhos quentes O(N²), vazamentos de identidade ThreadLocal ou log de credenciais. A lacuna entre 'conhecível' e 'detectável' é a lacuna entre uma teoria e sua operacionalização como infraestrutura automatizada.
MOAD existe porque o campo construiu infraestrutura de correção e não infraestrutura de desempenho ou segurança no mesmo nível. Testes unitários: padrão desde os anos 1970. Testes baseados em propriedades: padrão desde os anos 1990. Benchmarks de complexidade algorítmica em CI: ainda experimentais em 2026.
Operacionalizando o Alerta
Hamming alertou sobre calcificação de complexidade, propriedades não testadas, soluções copiadas sem suas condições e escala esmagando suposições iniciais. Ele nos deu o vocabulário. Ele não nos deu o detector.
O pipeline MOAD preenche essa lacuna: scan → ticket → patch → unit test → disclose → PR → upstream merge. Isso é Hamming operacionalizado: não apenas o alerta, mas detecção automatizada e um pipeline de correção.
A Assinatura Fester
Um defeito da classe MOAD possui uma assinatura reconhecível. Todas as cinco condições presentes simultaneamente. Todas as cinco são verificáveis antes de escrever uma única varredura:
1. Saída correta? Execute a suíte de testes padrão. Se passar, o defeito é de propriedade de desempenho ou segurança, não de correção. Isso significa que o CI padrão não o detectará.
2. Sem teste de complexidade? Verifique a configuração da CI. Existe uma etapa de benchmark? Ela compara o comportamento algorítmico (e não apenas o tempo de execução) com um commit anterior? Se não: condição presente.
3. Origem em N pequeno? Verifique o git blame e o commit original. Qual era o tamanho do conjunto de dados na primeira implementação? Esse tamanho é mais de 100× menor que a carga atual em produção? Se sim: condição presente.
4. A cópia se propaga? Procure o padrão em toda a base de código e em diferentes ecossistemas. O mesmo padrão estrutural aparece em N≥3 bases de código independentes sem ancestralidade compartilhada? Se sim: o fóssil se propagou. Cada cópia: um novo ponto de infecção.
5. A escala cresce? Verifique as métricas de produção. Qual é o valor de N hoje em comparação com N no primeiro deploy? A taxa de crescimento é sustentada? Em qual valor de N o defeito se torna criticamente operacional?
Se todos os cinco itens forem verificados e confirmados: você tem um defeito da classe MOAD. A correção é sempre uma substituição de uma linha ou de um método. A descoberta é a parte difícil. A correção é a parte fácil.
É isso que Hamming quis dizer: engenharia não é sobre a correção. A correção é direta uma vez que você a vê. Engenharia é sobre construir os sistemas que permitem que você a veja.
Aplique a Assinatura
A assinatura de infecção MOAD: saída correta + sem teste de complexidade + origem em N pequeno + cópia se propaga + escala cresce.
Esta assinatura não se limita aos cinco defeitos MOAD. Ela descreve uma classe de defeito que persiste em qualquer sistema onde testes de corretude são o único portão automatizado de qualidade.