As 20 Leis Secretas da Matrix da Engenharia de Software (Bizarres Rules)

 

Bellacosa Mainframe e as 20 leis secretas da Engenharia do Software

☕ Um Café no Bellacosa Mainframe

As 20 Leis Secretas da Matrix da Engenharia de Software - Bizarres Rules

O Guia do Programador COBOL Padawan para Sobreviver ao Universo dos Sistemas Legados Sem Ser Absorvido pelo Agente Smith

"Existem duas maneiras de aprender Engenharia de Software. A primeira é passando vinte anos corrigindo bugs em produção. A segunda é ouvindo aqueles que já passaram por isso. Este artigo tenta economizar duas décadas da sua vida."

---

Bem-vindo à Matrix, Padawan

Imagine a seguinte cena.

Você acabou de conseguir seu primeiro emprego como Programador COBOL.

Recebe acesso ao ambiente.

TSO.

ISPF.

CICS.

Db2.

JCL.

Tudo parece misterioso.

Então seu líder aponta para um programa com 180 mil linhas de código.

Ele sorri.

— Pequena manutenção.

Você abre o código.

O ventilador do computador começa a girar mais rápido.

Sua expressão muda.

Você pergunta:

— Quem escreveu isso?

A resposta vem imediatamente.

— Ninguém sabe.

Naquele instante o telefone toca.

É Morpheus.

— Neo... digo... Padawan...

Bem-vindo à Matrix da Engenharia de Software.

---

Existe um lado oculto da programação

Quando começamos a estudar programação, aprendemos:

• IF

• PERFORM

• LOOP

• SQL

• APIs

• Arquivos

• Variáveis

Mas ninguém ensina algo muito mais importante.

Os padrões invisíveis.

Os comportamentos humanos.

Os erros que se repetem geração após geração.

As armadilhas psicológicas.

As decisões arquiteturais.

Essas "leis" não pertencem ao COBOL.

Nem ao Java.

Nem ao Python.

Elas pertencem à natureza humana.

E é justamente por isso que continuam válidas há décadas.

---

A Matrix é feita de padrões

No filme Matrix, Neo acredita que tudo acontece por acaso.

Depois descobre que existem regras invisíveis governando aquele universo.

Na Engenharia de Software acontece exatamente a mesma coisa.

Você acha que aquele sistema virou um caos "do nada".

Não virou.

Ele seguiu um padrão.

Sempre segue.

---

O Oráculo chama isso de experiência

Imagine o Oráculo olhando para um jovem desenvolvedor.

Ela não pergunta:

— Você sabe COBOL?

Ela pergunta:

— Quantas vezes você já viu um sistema quebrar exatamente da mesma forma?

Porque experiência não é decorar comandos.

É reconhecer padrões.

---

Conheça as 20 Leis Secretas da Matrix da Engenharia de Software

Cada uma delas parece engraçada.

Algumas possuem nomes estranhos.

Outras parecem piadas.

Mas todas escondem décadas de aprendizado acumulado.

Vamos atravessar esse espelho.

---

1 — Bus Factor

"E se o único que entende o sistema for atropelado por um ônibus?"

Essa lei nos lembra que conhecimento concentrado é um enorme risco.

Se apenas uma pessoa entende o sistema...

...o sistema pertence a ela.

Não à empresa.

O verdadeiro Jedi documenta.

Compartilha.

Ensina.

https://eljefemidnightlunch.blogspot.com/2020/05/o-fator-onibus-o-dia-em-que-um.html

---

2 — Technical Debt

Toda gambiarra possui juros.

Às vezes ela resolve o problema hoje.

Mas cobra muito mais amanhã.

Como diria o Oráculo:

"A dívida técnica nunca esquece seu endereço."

https://eljefemidnightlunch.blogspot.com/2021/10/technical-debt-rules-quando-um.html 

---

3 — Yak Shaving

Você abriu um chamado simples.

Cinco horas depois.

Está configurando Docker.

Atualizando certificado.

Mudando firewall.

Lendo RFC.

Esqueceu completamente o problema inicial.

Parabéns.

Você encontrou um Yak.

https://eljefemidnightlunch.blogspot.com/2021/09/yak-shaving-rules-quando-um-programador.html

---

4 — Bike Shedding

Reunião de duas horas.

Noventa minutos discutindo a cor do botão.

Cinco minutos falando da arquitetura.

O Agente Smith adora reuniões assim.

https://eljefemidnightlunch.blogspot.com/2021/08/bike-shedding-rules-quando-um.html

---

5 — Golden Hammer

Quando tudo parece prego...

...qualquer ferramenta vira martelo.

O Padawan aprende Java.

Quer resolver tudo com Java.

Aprende IA.

Agora tudo precisa de IA.

Aprende Kubernetes.

Até o bloco de notas vira microsserviço.

Calma.

Nem toda batalha precisa da Nebuchadnezzar.

https://eljefemidnightlunch.blogspot.com/2021/07/golden-hammer-rules-quando-um.html

---

6 — Cargo Cult Programming

CTRL+C.

CTRL+V.

Funcionou.

Mas...

Você sabe por quê?

Se não sabe.

Talvez esteja apenas repetindo um ritual.

Não programação.

https://eljefemidnightlunch.blogspot.com/2021/05/spaghetti-code-rules-quando-um.html

---

7 — Spaghetti Code

IF dentro de IF.

GO TO.

PERFORM.

Mais GO TO.

Mais IF.

O código parece um prato de macarrão.

Delicioso no almoço.

Horrível na manutenção.

https://eljefemidnightlunch.blogspot.com/2021/05/spaghetti-code-rules-quando-um.html

---

8 — Lasagna Code

Agora temos o problema contrário.

Camadas.

Mais camadas.

Mais camadas.

Mais uma camada.

No final.

Um IF precisa atravessar sete microsserviços para mudar um campo.

https://eljefemidnightlunch.blogspot.com/2021/03/lasagna-code-rules-quando-um.html

---

9 — Big Ball of Mud

É aquele sistema onde ninguém sabe explicar a arquitetura.

Funciona?

Funciona.

Como?

Boa pergunta.

https://eljefemidnightlunch.blogspot.com/2021/01/big-ball-of-mud-rules-quando-um.html

---

10 — God Object

Existe um programa chamado:

CLIENTE01.

Ele faz:

• cadastro;

• cobrança;

• PIX;

• cartão;

• empréstimo;

• café;

• provavelmente também controla o clima.

Esse programa acredita ser o Escolhido.

Não é.

https://eljefemidnightlunch.blogspot.com/2020/11/god-object-rules-quando-um-programador.html

---

11 — Lava Flow

Código escrito em 1994.

Ninguém sabe para que serve.

Mas ninguém remove.

Vai que explode.

Então permanece.

Como lava endurecida.

https://eljefemidnightlunch.blogspot.com/2020/12/lava-flow-rules-quando-um-programador.html

---

12 — Boiling Frog

O sistema não piora de um dia para outro.

Vai ficando lentamente mais lento.

Mais complicado.

Mais difícil.

Quando percebemos.

Já estamos mergulhados na água fervendo.

https://eljefemidnightlunch.blogspot.com/2021/11/boiling-frog-rules-quando-um.html

---

13 — Death March

Prazo impossível.

Equipe pequena.

Escopo gigante.

Cliente ansioso.

Café infinito.

Dormir virou luxo.

Esse projeto nunca deveria ter começado assim.

https://eljefemidnightlunch.blogspot.com/2021/02/death-march-project-rules-quando-um.html

---

14 — Brooks's Law

O projeto está atrasado.

A solução?

Contratar vinte pessoas.

Resultado?

Agora existem vinte pessoas tentando entender o sistema.

E o atraso aumenta.

https://eljefemidnightlunch.blogspot.com/2020/09/brookss-law-rules-quando-um-programador.html

---

15 — Conway's Law

As equipes desenham software exatamente como se comunicam.

Se departamentos não conversam.

Os sistemas também não conversarão.

https://eljefemidnightlunch.blogspot.com/2020/08/conways-law-rules-quando-um-programador.html

---

16 — Murphy's Law

Tudo que pode falhar...

Vai falhar.

Especialmente sexta-feira.

Às 18h.

Cinco minutos antes da implantação.

Por isso existem testes.

https://eljefemidnightlunch.blogspot.com/2020/01/murphys-law-quando-um-programador-cobol.html

---

17 — KISS

Se ficou complicado demais...

Provavelmente existe uma solução mais simples.

Os melhores sistemas normalmente parecem óbvios.

Depois de prontos.

https://eljefemidnightlunch.blogspot.com/2020/02/kiss-rules-quando-um-programador-cobol.html

---

18 — YAGNI

"Vai que um dia precisamos..."

Essa frase já criou milhões de linhas de código inútil.

Implemente quando realmente precisar.

https://eljefemidnightlunch.blogspot.com/2020/07/yagni-rules-quando-um-programador-cobol.html

---

19 — DRY

Copiou.

Colou.

Copiou novamente.

Agora o bug existe em dezoito lugares diferentes.

Parabéns.

Você criou um exército de Agentes Smith.

https://eljefemidnightlunch.blogspot.com/2020/06/dry-rules-quando-um-programador-cobol.html

---

20 — SOLID

Os cinco pilares.

O alicerce.

A estrutura.

A arquitetura.

Sem eles.

O software continua funcionando.

Por algum tempo.

Depois...

A Matrix desaba.

https://eljefemidnightlunch.blogspot.com/2020/04/solid-roules-quando-um-programador.html

---

21 — Boy Scout Rule

Sim.

Ela veio depois.

Porque nenhum sistema melhora sozinho.

Toda vez que tocar em um programa.

Deixe-o um pouco melhor.

Nem que seja apenas renomeando uma variável.

https://eljefemidnightlunch.blogspot.com/2020/03/boy-scout-rule-quando-um-programador.html

---

O verdadeiro inimigo nunca foi a tecnologia

Perceba algo curioso.

Nenhuma dessas leis fala de:

COBOL.

Java.

Python.

Rust.

Go.

Todas falam sobre pessoas.

Porque software é uma atividade humana.

---

O Agente Smith mora dentro da nossa cabeça

Smith aparece quando pensamos:

• "Depois eu arrumo."

• "Só desta vez."

• "Ninguém vai perceber."

• "Pode copiar."

• "Não precisa documentar."

• "Vai funcionar."

É exatamente assim que grandes sistemas envelhecem.

---

Neo nunca venceu sozinho

Observe Matrix novamente.

Neo nunca salvou o mundo sozinho.

Precisou de:

• Morpheus;

• Trinity;

• Oráculo;

• Link;

• Tank;

• Niobe;

• Sati;

• Chaveiro.

Grandes sistemas também são construídos por equipes.

---

E onde entra o COBOL?

Em todos os lugares.

Os sistemas COBOL que movimentam bancos, seguradoras, bolsas de valores e governos não sobreviveram cinquenta anos porque alguém escreveu um código perfeito.

Eles sobreviveram porque milhares de engenheiros aplicaram — muitas vezes sem conhecer os nomes — esses princípios ao longo das décadas:

• simplificaram;

• documentaram;

• removeram duplicações;

• dividiram responsabilidades;

• testaram;

• compartilharam conhecimento;

• fizeram pequenas melhorias contínuas.

É por isso que um programa COBOL de 1988 ainda pode estar processando milhões de transações diariamente.

---

O Convite do Oráculo

No final da jornada, o Oráculo entrega a Neo um pequeno caderno.

Na capa está escrito:

"As Leis Secretas da Engenharia de Software."

Neo pergunta:

— Depois que eu decorar todas elas, finalmente serei um grande programador?

Ela sorri.

— Não.

— Então para que servem?

Ela responde:

"Porque agora, quando encontrar um problema, você saberá dar um nome ao monstro. E quando um monstro tem nome, ele deixa de parecer invencível."

---

Continue Explorando a Matrix

Se este artigo despertou sua curiosidade, esta é apenas a porta de entrada.

Cada uma dessas vinte (e uma) regras esconde uma história fascinante, repleta de exemplos reais, armadilhas clássicas, curiosidades históricas e lições que moldaram a engenharia de software moderna.

Nos próximos artigos da série ☕ Um Café no Bellacosa Mainframe, vamos mergulhar em cada uma delas com profundidade, sempre sob a ótica de um Programador COBOL Padawan explorando os corredores da Matrix.

Você descobrirá por que projetos fracassam, como sistemas sobrevivem por décadas, o que diferencia arquiteturas elegantes de verdadeiros labirintos de código e, principalmente, como transformar conhecimento técnico em sabedoria prática.

A cada regra desvendada, você enxergará um pouco mais do código verde da Matrix.

---

Conclusão — A Matrix Sempre Esteve na Engenharia de Software

No primeiro filme, Morpheus diz a Neo que a Matrix está em toda parte.

Na Engenharia de Software acontece exatamente o mesmo.

Essas leis aparecem:

• em pequenos scripts;

• em APIs modernas;

• em aplicações mobile;

• em microsserviços;

• em sistemas bancários;

• em programas COBOL escritos há quarenta anos;

• e até nas respostas geradas por Inteligências Artificiais.

Elas não são modismos.

São observações acumuladas por milhares de engenheiros que erraram, aprenderam, compartilharam e deixaram um mapa para quem veio depois.

Talvez você ainda não tenha encontrado todas essas situações.

Mas, acredite, se continuar programando, elas encontrarão você.

A boa notícia é que, agora, você já conhece seus nomes.

E isso faz toda a diferença.

No universo Bellacosa Mainframe, existe uma última frase escrita na parede da sala do Arquiteto:

"Todo Padawan começa aprendendo comandos. Todo Mestre termina reconhecendo padrões. Porque linguagens mudam, tecnologias envelhecem e frameworks desaparecem, mas as leis da Engenharia de Software continuam governando a Matrix muito depois que o último deploy termina."

Então pegue seu café.

Abra seu editor COBOL.

E venha explorar essas estranhas, divertidas e surpreendentemente verdadeiras regras da Engenharia de Software.

A Matrix está esperando por você.

DRY Rules: Quando um Programador COBOL Descobriu que Existiam Mil Agentes Smith Porque Alguém Copiou o Mesmo Código Pela Matrix Inteira

 

Bellacosa Mainframe e a dry rules

☕ Um Café no Bellacosa Mainframe

DRY Rules sem Mistérios

Quando um Programador COBOL Descobriu que Existiam Mil Agentes Smith Porque Alguém Copiou o Mesmo Código Pela Matrix Inteira

"Duplicar código parece economizar alguns minutos hoje. Mas pode custar centenas de horas durante a vida inteira de um sistema."

---

Prólogo — A Invasão dos Mil Smiths

Neo corria pelos corredores da Matrix.

De repente.

Encontrou um Agente Smith.

Depois outro.

Depois dez.

Depois cem.

Depois milhares.

Todos eram idênticos.

Todos repetiam exatamente as mesmas frases.

Os mesmos movimentos.

Os mesmos ataques.

Neo perguntou ao Oráculo:

— Como isso aconteceu?

Ela respondeu serenamente:

— Alguém resolveu copiar em vez de reutilizar.

Neo ficou confuso.

— O que isso tem a ver com programação?

O Oráculo apontou para o código-fonte da Matrix.

Cada módulo possuía a mesma lógica repetida dezenas de vezes.

Mudava apenas um pequeno detalhe.

O Arquiteto apareceu.

Suspirou profundamente.

— Agora precisamos corrigir um bug.

Neo perguntou:

— Quantos lugares teremos que alterar?

O Arquiteto respondeu:

— Ainda estamos contando...

Naquele instante Neo compreendeu que o verdadeiro inimigo não era Smith.

Era a duplicação.

---

O que significa DRY?

DRY significa:

Don't Repeat Yourself

Em português:

"Não se repita."

É um dos princípios mais importantes da Engenharia de Software.

Sua ideia é simples.

Cada conhecimento deve existir em apenas um lugar.

Quando uma regra aparece repetida em vários pontos do sistema, surge um risco enorme.

Se a regra mudar.

Será necessário alterar todos os lugares.

Se esquecer apenas um.

O sistema ficará inconsistente.

---

A origem do DRY

O princípio foi apresentado em 1999 por Andy Hunt e Dave Thomas, no livro clássico:

The Pragmatic Programmer

Os autores definiram o DRY de forma elegante:

"Every piece of knowledge must have a single, unambiguous, authoritative representation within a system."

Ou seja.

Cada informação importante deve possuir uma única fonte oficial.

---

Matrix explica perfeitamente

Imagine que existam cinquenta versões diferentes da regra que controla a gravidade da Matrix.

Uma delas diz:

Gravidade = 9,8

Outra.

Gravidade = 9,7

Outra.

Gravidade = 10

O resultado?

Cada região da Matrix funciona de maneira diferente.

---

O COBOL conhece muito bem o DRY

Imagine uma regra tributária.

Ela aparece em:

• Cadastro.

• Cobrança.

• Empréstimos.

• Cartões.

• PIX.

• Internet Banking.

Tudo copiado.

Chega uma nova legislação.

Agora será preciso alterar:

seis programas.

Se esquecer apenas um.

Problema.

---

Um exemplo COBOL

Primeiro programa.

IF SALDO < 0
   MOVE "N" TO APROVADO
END-IF

Segundo programa.

A mesma regra.

Terceiro.

Novamente.

Décimo.

Também.

Agora imagine.

A regra muda.

Saldo igual a zero também deve ser negado.

Quantos programas precisam mudar?

---

O COPYBOOK nasceu justamente para isso

Um dos maiores exemplos de DRY no COBOL.

Em vez de repetir estruturas.

Criamos:

COPY CLIENTE.

Agora.

Se o layout mudar.

Mudamos apenas um lugar.

---

Matrix Reloaded

Smith tornou-se perigoso justamente porque começou a se copiar infinitamente.

O mesmo acontece com regras de negócio.

Quanto mais cópias.

Mais difícil controlar.

---

O efeito psicológico

Existe uma tentação enorme.

"Vou copiar rapidinho."

Leva:

dez segundos.

Depois.

O sistema vive vinte anos.

---

O Programador COBOL Padawan

Você escreve:

CALCULA-JUROS.

Depois precisa da mesma lógica.

Em vez de criar uma rotina reutilizável.

Faz:

CTRL+C.

CTRL+V.

Parece eficiente.

Até a primeira manutenção.

---

O Agente Smith ama CTRL+C CTRL+V

Porque cada cópia.

É um novo esconderijo para bugs.

Um erro copiado.

É um erro multiplicado.

---

Um exemplo inspirado na Matrix

Imagine.

Existem cinquenta mapas de Zion.

Cada mapa possui uma pequena diferença.

Qual deles é verdadeiro?

Ninguém sabe.

---

O custo invisível

Duplicação gera:

• manutenção maior;

• testes maiores;

• documentação maior;

• bugs inconsistentes;

• dificuldade de evolução.

---

O impacto no Mainframe

Grandes ambientes IBM Z frequentemente apresentam:

• COPYBOOKs duplicados;

• layouts semelhantes;

• SQL repetido;

• JCLs quase idênticos;

• validações copiadas.

Quanto maior a duplicação.

Maior o esforço de manutenção.

---

Curiosidade

DRY não trata apenas de código.

Também vale para:

• documentação;

• configurações;

• tabelas;

• scripts;

• APIs;

• processos.

Conhecimento duplicado também é duplicação.

---

Atenção!

DRY não significa:

Transformar tudo em reutilização.

Existe outro princípio importante.

AHA

Avoid Hasty Abstractions.

Evite abstrações prematuras.

Primeiro compreenda o padrão.

Depois reutilize.

---

A diferença

Reutilização saudável

Uma regra.

Um local.

---

Reutilização exagerada

Tudo depende de um único módulo gigantesco.

---

Matrix e o Chaveiro

O Chaveiro fabrica uma chave para cada tipo de porta.

Mas não fabrica cem cópias da mesma chave escondidas pela Matrix.

Existe uma fonte.

Uma responsabilidade.

---

Ferramentas ajudam

Hoje temos:

• SonarQube.

• IBM ADDI.

• Enterprise Analyzer.

• Clone Detection.

• Code Review.

• IA.

Todas ajudam a localizar duplicações.

---

O papel da IA

A IA consegue detectar:

• código semelhante;

• SQL repetido;

• COPYBOOKs equivalentes;

• regras duplicadas.

Mas cabe ao arquiteto decidir como consolidar.

---

Os riscos

Ignorar DRY gera.

• inconsistências.

• bugs.

• retrabalho.

• dívida técnica.

• manutenção cara.

• baixa produtividade.

---

Erros clássicos

• Copiar programas inteiros.

• Duplicar SQL.

• Repetir validações.

• Criar layouts quase iguais.

• Duplicar documentação.

---

Boas práticas

• Modularizar.

• Criar COPYBOOKs.

• Utilizar subprogramas.

• Centralizar regras.

• Automatizar validações.

• Revisar duplicações periodicamente.

---

Aplicabilidade

DRY aparece em:

• COBOL.

• Java.

• Python.

• C#.

• APIs.

• Cloud.

• DevOps.

• Scripts.

• SQL.

• Infraestrutura como Código.

---

DRY e o universo IBM Z

O ecossistema IBM Z oferece diversos mecanismos que incorporam naturalmente o espírito do DRY.

Entre eles:

• COPYBOOKs, para compartilhar layouts de dados entre programas.

• Subprogramas COBOL, evitando repetir regras de negócio.

• Stored Procedures Db2, centralizando lógica próxima aos dados quando apropriado.

• PROCs JCL, reutilizando definições de execução.

• Macros HLASM, eliminando repetições em código Assembly.

• Serviços CICS compartilhados, reutilizados por diferentes transações.

• APIs corporativas, permitindo que uma única implementação atenda vários consumidores.

Todos esses recursos existem para evitar que o mesmo conhecimento seja implementado repetidamente.

---

Quando DRY pode ser exagerado?

Assim como qualquer princípio, o DRY pode ser levado ao extremo.

Imagine duas regras de negócio parecidas, mas que pertencem a domínios diferentes.

Forçá-las a usar a mesma rotina apenas porque "são semelhantes" pode criar um forte acoplamento.

Meses depois, uma regra muda.

A outra não.

Agora a reutilização passa a atrapalhar.

Por isso muitos arquitetos repetem uma frase importante:

"Não reutilize por preguiça de escrever código. Reutilize porque existe realmente um conhecimento comum."

---

DRY conversa com toda esta série

Ao longo dos artigos Bellacosa Mainframe, você já encontrou diversos princípios que se relacionam diretamente com o DRY.

Ele ajuda a evitar:

• Spaghetti Code, reduzindo trechos repetidos espalhados pelo sistema.

• Golden Hammer, porque incentiva pensar antes de copiar soluções.

• Lava Flow, evitando múltiplas versões abandonadas da mesma regra.

• Big Ball of Mud, diminuindo a desorganização.

• KISS, favorecendo soluções claras e centralizadas.

• YAGNI, impedindo a criação de módulos duplicados "para o futuro".

Perceba que todos esses princípios caminham na mesma direção:

software simples, consistente e sustentável.

---

O ensinamento do Oráculo

O Oráculo entrega a Neo um enorme livro.

Cada capítulo conta exatamente a mesma história.

Neo pergunta:

— Por que repetir tudo isso?

Ela sorri.

Depois entrega outro livro.

Nele existe apenas uma história.

Todos os capítulos fazem referência a ela.

Neo entende imediatamente.

Ela então diz:

"A verdade precisa existir apenas uma vez. Todas as cópias são oportunidades para que ela deixe de ser verdade."

---

Lições para um Programador COBOL Padawan

Durante sua jornada no universo IBM Z, você encontrará muitas oportunidades de usar o famoso CTRL+C / CTRL+V.

À primeira vista parece uma solução rápida.

Mas faça uma pausa.

Pergunte a si mesmo:

• Essa regra já existe em outro lugar?

• Posso transformá-la em um subprograma?

• Um COPYBOOK resolveria?

• Essa validação deveria ser centralizada?

• Estou duplicando conhecimento ou apenas reutilizando uma estrutura?

Essas perguntas fazem enorme diferença ao longo dos anos.

Lembre-se de que a maior parte do custo de um software está na manutenção.

Quanto menos lugares precisarem ser alterados para implementar uma mudança de negócio, maior será a qualidade do sistema.

---

Curiosidades

O princípio DRY influenciou profundamente diversas tecnologias modernas:

• Domain-Driven Design, incentivando uma única fonte para conceitos do domínio.

• APIs REST e GraphQL, centralizando serviços reutilizáveis.

• Infrastructure as Code, eliminando configurações duplicadas.

• GitHub Actions, reutilizando pipelines.

• Ansible, através de roles e playbooks compartilhados.

• Kubernetes, reutilizando manifestos e templates.

• CI/CD, automatizando tarefas repetitivas em vez de executá-las manualmente.

A ideia permanece exatamente a mesma apresentada por Hunt e Thomas em 1999: uma única representação confiável para cada conhecimento.

---

Conclusão — A Matrix Não Precisava de Mil Smiths

No final de Matrix Reloaded e Matrix Revolutions, Smith tornou-se uma ameaça justamente porque sua capacidade de se replicar saiu do controle.

Na Engenharia de Software acontece algo semelhante.

Cada regra copiada, cada SQL duplicado, cada validação repetida cria mais uma versão da mesma verdade.

E quando a verdade muda, todas as cópias precisam mudar junto.

O princípio DRY nos lembra que software sustentável depende de uma única fonte de conhecimento para cada regra importante.

Para um Programador COBOL que trabalha com IBM Z, isso significa valorizar COPYBOOKs, subprogramas, APIs compartilhadas e componentes reutilizáveis, sempre com equilíbrio e sem criar abstrações artificiais.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria escrita na oficina do Chaveiro:

"Se uma única chave abre todas as portas corretas, cuide bem dela. Construir cem cópias da mesma chave apenas torna mais difícil descobrir qual delas ainda funciona."

Porque, assim como Neo descobriu que um único Escolhido era mais poderoso do que milhares de cópias imperfeitas de Smith, um sistema também se torna muito mais confiável quando cada conhecimento existe em um único lugar, claro, bem documentado e fácil de manter.