Lei de Hyrum: as regras escondidas no sistema legado

Muitos diretores de TI já ouviram, ou já disseram, a frase: “o sistema novo faz tudo o que o antigo fazia”. E muitos já viram essa frase desmoronar logo depois da troca, quando um setor inteiro descobre que algo “simplesmente parou de funcionar”, embora ninguém tenha pedido aquilo em nenhuma reunião de requisitos.

Isso não é azar nem falha de um fornecedor específico. É um fenômeno tão previsível que ganhou nome: a Lei de Hyrum.

O que diz a Lei de Hyrum?

A ideia foi formulada por Hyrum Wright, a partir da experiência com migrações de infraestrutura no Google, e diz, em tradução livre: com um número suficiente de usuários de uma API, não importa o que foi prometido no contrato: todo comportamento observável do sistema vai acabar sendo usado por alguém.

A observação nasceu para interfaces de software, mas vale igualmente para pessoas, planilhas e processos que dependem de um sistema.

Em outras palavras, um sistema tem duas descrições. Uma é a oficial: o manual, a especificação, o que foi contratado. A outra é a real: tudo o que ele de fato faz, incluindo detalhes que ninguém planejou, como a ordem em que os itens aparecem num relatório, o formato de um arquivo exportado ou o horário exato em que uma rotina noturna termina. Com o tempo, as pessoas e os outros sistemas passam a depender da descrição real, não da oficial.

Quanto mais antigo e mais usado o sistema, maior a distância entre as duas. É no legado que essa lei aparece com mais força.

Como isso aparece no dia a dia?

Alguns exemplos que se repetem em empresas de todos os portes:

O relatório que vira integração. O ERP antigo gera um relatório em texto com colunas sempre na mesma posição. Alguém do financeiro criou uma planilha que lê esse arquivo e alimenta a conciliação bancária. O sistema novo gera um relatório mais bonito, em outro layout, e a conciliação para no dia seguinte.

O erro que vira regra de negócio. Um cálculo de desconto arredonda sempre para baixo por causa de uma limitação antiga. Ao longo de anos, a tabela de preços e os contratos de clientes foram ajustados levando esse arredondamento em conta. O sistema novo calcula “certo” e passa a gerar divergências em centenas de notas.

A lentidão que vira controle. Uma aprovação de pedido demora alguns minutos para refletir no estoque. A equipe de expedição aprendeu a usar esse intervalo para conferir pedidos grandes. Quando o processo fica instantâneo, a conferência some, e os erros de separação aparecem.

Em nenhum desses casos o comportamento estava documentado. Ele simplesmente existia, e alguém passou a confiar nele.

Por que isso é um assunto de negócio, e não só de TI?

Porque o custo da Lei de Hyrum aparece justamente nos momentos em que a empresa está tentando evoluir: na troca de ERP, na migração para a nuvem, na integração com um parceiro ou na conexão de um agente de IA aos sistemas internos.

O orçamento e o cronograma desses projetos costumam ser feitos a partir da descrição oficial do sistema. As dependências invisíveis só aparecem depois da virada, quando custam mais caro: retrabalho, operação parada, multa contratual, cliente insatisfeito. É uma das formas mais concretas da dívida técnica dos sistemas legados.

Existe também o efeito contrário, mais silencioso: o medo. Quando ninguém sabe o que depende do quê, a decisão mais segura parece ser não mexer em nada. O sistema fica congelado, e a empresa paga por isso em agilidade.

A cerca no meio do caminho

O escritor inglês G. K. Chesterton descreveu, em 1929, uma situação que todo gestor reconhece. Um reformador encontra uma cerca no meio de uma estrada e quer derrubá-la porque não vê utilidade nela. O conselho de Chesterton: não derrube enquanto não descobrir por que ela foi colocada ali.

No legado, cada comportamento estranho é uma dessas cercas. Pode ser só um resto inútil, ou pode estar segurando um processo crítico. A resposta certa não é preservar tudo nem descartar tudo, e sim investigar antes de decidir.

Como descobrir o que o sistema realmente faz?

O trabalho tem três frentes que se complementam:

Observar o uso real. Registrar quem consome cada relatório, arquivo e tela; quais integrações leem quais tabelas; quais rotinas rodam e em que horário. Logs e monitoramento mostram dependências que nenhuma entrevista revela.

Ler o código como fonte de regras. Em sistemas antigos, o código costuma ser a única documentação fiel das regras de negócio. Aqui a inteligência artificial ajuda de forma prática: ferramentas de IA conseguem percorrer milhares de linhas, explicar em linguagem simples o que cada rotina faz e apontar cálculos, exceções e condições que merecem atenção. A IA não substitui a validação de quem conhece o negócio, mas acelera a leitura manual e entrega uma lista organizada de perguntas para validar.

Transformar o comportamento em testes. Antes de mudar qualquer coisa, registrar em testes automatizados o que o sistema faz hoje, com entradas e saídas reais, os chamados testes de caracterização. Assim, toda mudança mostra imediatamente o que deixou de ser igual, e a equipe decide, caso a caso, se aquela diferença é uma correção desejada ou uma quebra. É a base da modernização de sistemas legados sem risco.

Como a RETTA pode ajudar?

A RETTA atua na manutenção e modernização de sistemas legados. Mapeamos as dependências, levantamos com apoio de IA as regras que só existem no código e transformamos esse comportamento em testes. Assim, a sua equipe decide o que preservar e o que corrigir, e a evolução acontece sem parar a operação.

Vai trocar, integrar ou conectar IA a um sistema antigo? Fale com a nossa equipe e descubra o que o seu legado faz antes que a operação descubra por você.