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ê.

YAGNI Rules: Quando um Programador COBOL Descobriu que a Matrix Estava Cheia de Recursos Que Ninguém Jamais Usaria

 

Bellacosa Mainframe e a yagni rules

☕ Um Café no Bellacosa Mainframe

YAGNI Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Estava Cheia de Recursos Que Ninguém Jamais Usaria

"O código mais caro não é aquele que foi escrito. É aquele que foi escrito para um futuro que nunca chegou."

---

Prólogo — O Depósito das Funcionalidades Fantasma

Após derrotar mais uma legião de Agentes Smith, Neo recebeu um convite inesperado do Arquiteto.

— Hoje vou lhe mostrar um lugar que nem mesmo o Oráculo costuma visitar.

Os dois atravessaram uma enorme porta metálica escondida atrás do núcleo da Matrix.

Do outro lado havia um gigantesco depósito.

Prateleiras infinitas.

Milhões de linhas de código.

Módulos completos.

APIs.

Menus.

Botões.

Rotinas.

Neo perguntou:

— O que é tudo isso?

O Arquiteto respondeu:

— Funcionalidades.

Neo ficou impressionado.

— Quantas pessoas usam?

Silêncio.

Depois de alguns segundos o Arquiteto respondeu:

— Nenhuma.

Neo caminhou entre corredores intermináveis.

Encontrou módulos chamados:

FUTURO-PROJETO.

CLIENTE-PREMIUM-V3.

IA-EXPERIMENTAL.

RELATORIO-UNIVERSAL.

MODULO-MULTIMOEDA.

SISTEMA-DE-TELETRANSPORTE.

Perguntou:

— Isso tudo está em produção?

O Arquiteto respondeu.

— Está.

— Funciona?

— Sim.

— É usado?

— Nunca foi.

O Oráculo apareceu.

Serviu café para Neo.

Depois disse calmamente:

"O maior desperdício da engenharia não é escrever código ruim. É escrever código que jamais resolverá um problema real."

Naquele momento Neo compreendeu o verdadeiro significado do YAGNI.

---

O que significa YAGNI?

YAGNI significa:

You Aren't Gonna Need It

Em português:

"Você não vai precisar disso."

É um dos princípios mais conhecidos da metodologia Extreme Programming (XP).

Sua ideia é extremamente simples.

Não implemente hoje funcionalidades que talvez sejam necessárias amanhã.

Implemente apenas aquilo que resolve um problema existente.

---

A origem do princípio

O YAGNI surgiu no final da década de 1990 dentro do movimento Extreme Programming, criado por Kent Beck.

Na época, muitas equipes gastavam enorme quantidade de tempo construindo recursos para um futuro hipotético.

Esses recursos quase nunca eram utilizados.

Kent Beck propôs uma filosofia radical.

Construa somente aquilo que possui necessidade comprovada.

Quando surgir uma nova necessidade.

Implemente naquele momento.

---

Matrix explica perfeitamente

Imagine que o Arquiteto resolvesse prever todas as possibilidades da humanidade.

Então incluiria:

• controle de dragões;

• módulo para dinossauros;

• protocolo para viagens no tempo;

• economia marciana;

• integração com civilizações alienígenas.

Tudo isso "caso um dia seja necessário".

Resultado?

A Matrix seria gigantesca.

Difícil de manter.

Lenta.

Cheia de código inútil.

---

Como nasce o excesso?

Sempre começa com boas intenções.

Alguém diz.

"Vai que um dia..."

Depois aparecem frases como:

• "Já vamos deixar preparado."

• "Aproveita e cria também..."

• "É só mais um IF."

• "No futuro pode servir."

Meses depois.

Ninguém usa.

---

O COBOL conhece isso muito bem

Imagine um sistema bancário.

O requisito diz:

Calcular IOF.

O desenvolvedor pensa.

"Vai que um dia o banco trabalhe com Bitcoin, Ouro, Marte e Lua."

Então cria:

• vinte tabelas;

• quinze tipos de moeda;

• cinquenta parâmetros.

Quando entra em produção.

Existe apenas:

Real.

---

Um exemplo COBOL

Requisito.

Calcular juros.

Solução simples.

COMPUTE JUROS = SALDO * TAXA

Solução YAGNI ignorado.

Cria:

• Framework de cálculo.

• Plugin.

• Factory.

• Reflection.

• Configuração XML.

• API REST.

• Tabela dinâmica.

Tudo para multiplicar dois números.

---

Matrix Reloaded

O Arquiteto mostra milhares de possibilidades futuras.

Neo pergunta.

— Precisamos construir tudo isso?

O Arquiteto responde.

— Não.

O Oráculo sorri.

— O futuro ainda não decidiu existir.

---

O efeito psicológico

Existe um medo comum entre desenvolvedores.

"E se amanhã precisarmos?"

Essa pergunta gera enormes desperdícios.

Porque o amanhã raramente acontece exatamente como imaginamos.

---

O Programador COBOL Padawan

Imagine seu primeiro projeto.

O gerente pede:

— Precisamos gerar um relatório.

Você responde.

— Já vou criar vinte modelos diferentes.

Pergunta.

O cliente pediu vinte?

Não.

Pediu um.

---

O Agente Smith ama funcionalidades imaginárias

Porque cada funcionalidade extra gera:

• novos bugs;

• novos testes;

• nova documentação;

• novas dependências;

• novas exceções.

Quanto mais código.

Maior a superfície para ataques.

---

Um exemplo inspirado na Matrix

Neo pergunta.

— Quantas portas existem?

O Chaveiro responde.

— Mil.

Neo pergunta.

— Quantas usamos?

— Dez.

As outras novecentas e noventa foram criadas "caso um dia fossem necessárias".

---

O custo invisível

Toda funcionalidade possui custo.

Mesmo sem uso.

Ela precisa:

• compilar;

• ser testada;

• documentada;

• protegida;

• revisada;

• mantida.

Nada é gratuito.

---

O impacto no Mainframe

Em ambientes IBM Z aparecem frequentemente:

• COPYBOOKs preparados para campos inexistentes;

• layouts gigantes;

• tabelas nunca utilizadas;

• JCLs reservados para processos imaginários;

• programas chamados apenas "no futuro".

Tudo isso aumenta:

• CPU;

• armazenamento;

• manutenção.

---

Curiosidade

Diversos estudos em desenvolvimento de software mostram que uma parcela significativa das funcionalidades presentes em sistemas corporativos é usada muito raramente ou nunca é utilizada pelos usuários finais.

Isso reforça a importância de validar necessidades reais antes de implementar novas capacidades.

---

Atenção!

YAGNI não significa:

"Nunca pensar no futuro."

Significa:

"Não implementar antes da hora."

Arquitetura pode prever evolução.

Código desnecessário não.

---

A diferença

Preparar arquitetura

Permitir crescimento.

---

Implementar tudo

Criar desperdício.

---

Matrix e Zion

Imagine construir:

• cem hangares;

• mil naves;

• cinquenta hospitais.

Antes mesmo de saber quantas pessoas viverão em Zion.

Seria desperdício.

---

Ferramentas ajudam

Hoje podemos medir uso real.

• Telemetria.

• Analytics.

• Logs.

• Feature Flags.

• IBM Instana.

• OMEGAMON.

• Monitoramento de APIs.

Esses dados mostram o que realmente é utilizado.

---

O papel da IA

A IA frequentemente sugere funcionalidades extras.

Cabe ao engenheiro perguntar.

"O cliente pediu isso?"

Se a resposta for não.

Talvez seja YAGNI.

---

Os riscos

Ignorar YAGNI gera:

• overengineering;

• manutenção cara;

• código morto;

• testes maiores;

• documentação enorme;

• mais bugs.

---

Erros clássicos

• Programar para cenários imaginários.

• Criar abstrações prematuras.

• Implementar requisitos inexistentes.

• Confundir arquitetura extensível com funcionalidades prontas.

• Aceitar "vai que um dia".

---

Boas práticas

• Desenvolver apenas requisitos atuais.

• Validar com usuários.

• Medir utilização.

• Evoluir incrementalmente.

• Refatorar quando necessário.

• Simplificar continuamente.

---

Aplicabilidade

YAGNI aparece em:

• COBOL.

• Java.

• Python.

• Cloud.

• APIs.

• Microsserviços.

• Mobile.

• IA.

• DevOps.

• ERP.

---

Um exemplo COBOL

Cliente pede.

Cadastro de Endereço.

Você cria.

• Rua.

• Número.

• Cidade.

• Estado.

• CEP.

Não precisa adicionar:

• Colônia em Marte.

• Quadrante Galáctico.

• Planeta de Origem.

• Coordenadas Quânticas.

Até que alguém realmente peça.

---

YAGNI e os outros princípios

YAGNI conversa diretamente com quase todos os princípios estudados nesta série.

Ele reduz:

• Golden Hammer, porque evita criar soluções grandiosas para problemas pequenos.

• Lasagna Code, porque impede camadas desnecessárias.

• Lava Flow, porque evita código que nunca será usado e depois ninguém tem coragem de remover.

• Boiling Frog, porque impede o crescimento silencioso da complexidade.

• KISS, porque incentiva soluções simples.

• Death March, porque reduz trabalho desnecessário.

• Brooks's Law, porque menos funcionalidades significam menos necessidade de crescimento artificial da equipe.

YAGNI é um excelente antídoto contra o excesso de zelo que acaba produzindo desperdício.

---

O ensinamento do Oráculo

O Oráculo entrega uma mochila para Neo.

Dentro dela existem:

• vinte lanternas;

• quinze bússolas;

• dez rádios;

• cinco espadas;

• três computadores;

• duas cafeteiras.

Neo tenta levantá-la.

Não consegue.

Ela retira tudo.

Deixa apenas:

uma bússola.

água.

e uma lanterna.

Neo sorri.

— Agora consigo caminhar.

Ela responde.

"Quem leva tudo para uma jornada acaba sem forças para percorrê-la."

---

Lições para um Programador COBOL Padawan

Ao longo da carreira você ouvirá muitas sugestões começando com:

• "Já aproveita..."

• "Vai que..."

• "Quem sabe no futuro..."

• "Deixa preparado..."

Antes de aceitar, faça algumas perguntas:

• Existe um requisito aprovado?

• Há uma necessidade real?

• Algum usuário pediu isso?

• Existe previsão concreta de uso?

• Estamos aumentando a complexidade sem necessidade?

Se a resposta for "não", provavelmente você está diante de um caso clássico de YAGNI.

Projetar sistemas preparados para evoluir é excelente.

Implementar funcionalidades imaginárias é desperdício.

---

Curiosidades

O princípio YAGNI influenciou fortemente várias práticas modernas:

• Agile, priorizando valor entregue a cada iteração.

• Lean Software Development, eliminando desperdícios.

• Feature Flags, permitindo ativar funcionalidades apenas quando realmente necessárias.

• MVP (Minimum Viable Product), que incentiva lançar a menor solução capaz de gerar valor.

• Continuous Delivery, favorecendo evolução contínua em vez de grandes antecipações.

Todos compartilham a mesma ideia: desenvolva apenas aquilo que gera valor agora.

---

Conclusão — O Futuro Ainda Não Escreveu Seu Código

Quando Neo percorreu o depósito do Arquiteto, percebeu que milhares de módulos existiam apenas para responder a perguntas que ninguém jamais faria.

Na Engenharia de Software isso acontece com frequência.

O princípio YAGNI nos lembra que o futuro é imprevisível. As funcionalidades imaginadas hoje dificilmente corresponderão exatamente às necessidades reais de amanhã.

Para um Programador COBOL, especialmente em ambientes IBM Z onde estabilidade, desempenho e facilidade de manutenção são essenciais, escrever menos código costuma ser uma decisão mais inteligente do que escrever código "por precaução".

Cada linha adicionada representa mais testes, mais documentação, mais manutenção e mais oportunidades para o Agente Smith encontrar uma brecha.

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

"Não construa hoje a chave de uma porta que talvez nunca exista. Quando essa porta aparecer, você terá conhecimento, ferramentas e experiência para fabricar exatamente a chave de que ela precisa."

Porque o verdadeiro engenheiro não é aquele que tenta prever todos os futuros possíveis.

É aquele que constrói sistemas simples, elegantes e preparados para evoluir quando o futuro finalmente bater à porta.