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

KISS Rules : Quando um Programador COBOL Descobriu que o Arquiteto da Matrix Não Vencia Pela Complexidade… Mas Pela Simplicidade

  

Bellacosa Mainframe apresenta o KISS rules

☕ Um Café no Bellacosa Mainframe

KISS Rules sem Mistérios

Quando um Programador COBOL Descobriu que o Arquiteto da Matrix Não Vencia Pela Complexidade… Mas Pela Simplicidade

"A maior demonstração de inteligência não é construir algo complicado. É construir algo tão simples que continue funcionando décadas depois."

---

Prólogo — O Código Secreto do Arquiteto

Depois de inúmeras batalhas contra o Agente Smith, Neo finalmente teve acesso ao núcleo da Matrix.

Esperava encontrar algoritmos impossíveis.

Equações gigantescas.

Milhares de níveis de abstração.

Mas encontrou algo completamente diferente.

O coração da Matrix era surpreendentemente simples.

Poucas regras.

Poucas interfaces.

Poucos componentes.

Neo olhou espantado para o Arquiteto.

— Isso é tudo?

O Arquiteto respondeu calmamente.

— A complexidade não está no código.

Está no mundo.

Nos usuários.

Nos negócios.

Nos requisitos.

Nos imprevistos.

Neo insistiu.

— Então por que não criar uma arquitetura extremamente sofisticada?

O Oráculo apareceu.

Serviu duas xícaras de café.

Depois colocou sobre a mesa dois relógios.

Um possuía centenas de engrenagens.

Outro tinha poucas peças.

Perguntou:

— Qual você acha que continuará funcionando daqui a cinquenta anos?

Neo sorriu.

Naquele instante compreendeu o verdadeiro significado do KISS.

---

O que significa KISS?

KISS significa:

Keep It Simple, Stupid

Em português:

"Mantenha tudo o mais simples possível."

Apesar do termo "Stupid" soar ofensivo em português, ele nasceu como uma forma bem-humorada de lembrar engenheiros de que a simplicidade costuma ser mais poderosa do que soluções excessivamente sofisticadas.

Hoje muitas empresas preferem versões como:

• Keep It Simple

• Keep It Short and Simple

• Keep It Simple and Smart

Mas a essência permanece a mesma.

---

A origem do princípio

O princípio surgiu na década de 1960.

Foi popularizado pelo engenheiro Kelly Johnson, líder da famosa divisão Skunk Works, da Lockheed.

Johnson orientava sua equipe a desenvolver aviões militares extremamente eficientes, porém fáceis de manter em condições adversas.

Sua filosofia era simples:

Um mecânico em um campo de batalha deve conseguir reparar o avião com ferramentas comuns.

Se o projeto fosse complexo demais para ser mantido, ele já havia fracassado.

Décadas depois, esse princípio tornou-se um dos pilares da Engenharia de Software.

---

Matrix explica perfeitamente

Imagine duas versões da Matrix.

A primeira possui:

• cinco componentes;

• regras claras;

• comunicação simples.

A segunda possui:

• cinquenta frameworks;

• cem microsserviços;

• dezenas de filas;

• múltiplas camadas;

• configurações espalhadas.

Qual delas Neo conseguiria compreender primeiro?

Provavelmente a mais simples.

---

Simples não significa simplório

Esse é um dos maiores mal-entendidos.

KISS não significa fazer menos.

Significa fazer apenas o necessário.

Existe enorme diferença.

---

O COBOL nasceu seguindo KISS

Quando COBOL surgiu, seu objetivo era ser:

• legível;

• previsível;

• próximo da linguagem humana.

Observe.

ADD VALOR
   TO SALDO.

Ou.

IF CLIENTE-ATIVO

Mesmo décadas depois.

Ainda conseguimos entender.

Essa clareza foi uma decisão arquitetural.

---

Como nasce a complexidade?

Ela raramente aparece de uma vez.

Primeiro surge um pequeno framework.

Depois outro.

Depois uma camada.

Depois uma abstração.

Depois uma exceção.

Anos depois.

Ninguém consegue explicar a arquitetura completa.

---

Matrix Reloaded

O Arquiteto mostra para Neo inúmeras versões anteriores da Matrix.

Cada uma tornou-se mais sofisticada.

Mas também mais difícil de controlar.

Quanto maior a complexidade.

Maior o número de efeitos colaterais.

---

O efeito psicológico

Existe um fenômeno curioso.

Profissionais iniciantes frequentemente acreditam que:

"Código complicado impressiona."

Profissionais experientes descobrem justamente o contrário.

Código simples impressiona muito mais.

Porque é difícil escrever algo realmente simples.

---

O Programador COBOL Padawan

Imagine duas soluções.

Primeira.

IF CLIENTE-ATIVO

Segunda.

IF CLIENTE-ATIVO
   AND WS-FLAG-01 = "S"
   OR WS-FLAG-02 = "N"
   AND WS-STATUS-XYZ NOT = ZERO
   ...

Qual será compreendida daqui a quinze anos?

---

O Agente Smith ama complexidade

Porque sistemas complicados escondem:

• bugs;

• inconsistências;

• duplicações;

• vulnerabilidades.

Quanto mais difícil entender.

Mais difícil corrigir.

---

Um exemplo inspirado na Matrix

Neo precisa abrir uma porta.

Versão simples.

Uma chave.

Versão complexa.

Quatro chaves.

Cinco senhas.

Três certificados.

Dois tokens.

Sete validações.

No final.

A porta continua sendo apenas uma porta.

---

O custo invisível

Complexidade gera:

• treinamento maior;

• documentação maior;

• testes maiores;

• manutenção maior;

• risco maior.

Tudo cresce.

---

O impacto no Mainframe

Em ambientes IBM Z encontramos aplicações com quarenta anos de vida.

Sistemas assim sobrevivem porque muitos seguiram princípios como:

• simplicidade;

• modularização;

• previsibilidade;

• estabilidade.

Não porque eram sofisticados.

---

Curiosidade

Albert Einstein costuma receber a frase:

"Everything should be made as simple as possible, but not simpler."

Embora a autoria exata seja debatida, a ideia resume perfeitamente o KISS:

Simplifique.

Mas nunca elimine o essencial.

---

Quando KISS é ignorado?

Começam a surgir:

• frameworks desnecessários;

• padrões aplicados sem necessidade;

• heranças enormes;

• interfaces excessivas;

• configurações infinitas.

Tudo para resolver problemas simples.

---

Um exemplo COBOL

Imagine um cálculo.

Versão simples.

COMPUTE TOTAL = PRECO * QUANTIDADE

Versão complicada.

Três programas.

Cinco CALLs.

Duas APIs.

Uma fila MQ.

Resultado idêntico.

---

Matrix e o Chaveiro

O Chaveiro representa uma lição interessante.

Ele cria chaves.

Não cem ferramentas.

Cada chave resolve exatamente um problema.

Essa é uma excelente representação do KISS.

---

Atenção!

KISS não significa evitar arquitetura.

Significa evitar arquitetura desnecessária.

---

A diferença

Arquitetura Elegante

Resolve o problema.

---

Arquitetura Complicada

Cria novos problemas.

---

O papel da simplicidade

Sistemas simples apresentam:

• menos bugs;

• menor custo;

• maior previsibilidade;

• onboarding mais rápido;

• documentação menor.

---

Ferramentas ajudam

No universo IBM.

Ferramentas como:

• IBM ADDI;

• SonarQube;

• COBOL Check;

• Enterprise Analyzer;

ajudam a localizar:

• duplicações;

• complexidade ciclomática;

• código morto;

• módulos gigantes.

---

O papel da IA

A IA frequentemente sugere soluções sofisticadas.

Cabe ao engenheiro perguntar:

"Existe uma maneira mais simples?"

Essa talvez seja uma das perguntas mais importantes da profissão.

---

Os riscos

Quando KISS é ignorado.

Surgem:

• overengineering;

• manutenção cara;

• dependências excessivas;

• curva de aprendizado enorme;

• baixa produtividade.

---

Erros clássicos

• Adotar tecnologia apenas porque está na moda.

• Aplicar Design Patterns em todo lugar.

• Criar abstrações prematuras.

• Usar cinco frameworks quando um resolveria.

• Confundir inteligência com complexidade.

---

Boas práticas

• Resolver primeiro o problema.

• Medir antes de otimizar.

• Escrever código legível.

• Modularizar.

• Eliminar duplicações.

• Revisar continuamente.

• Questionar toda nova dependência.

---

Aplicabilidade

KISS aparece em:

• COBOL.

• CICS.

• Db2.

• Java.

• Python.

• APIs.

• Cloud.

• Kubernetes.

• Microsserviços.

• IA.

É um princípio universal.

---

KISS e os outros princípios

Curiosamente.

KISS conversa diretamente com vários conceitos já vistos nesta série.

Ele reduz:

• Spaghetti Code, porque incentiva clareza.

• Lasagna Code, porque evita camadas desnecessárias.

• Golden Hammer, porque escolhe apenas as ferramentas necessárias.

• Big Ball of Mud, porque favorece organização.

• Boiling Frog, porque dificulta o crescimento invisível da complexidade.

• Death March, porque soluções simples costumam ser entregues e testadas mais rapidamente.

Não é apenas um princípio isolado.

É uma filosofia que influencia praticamente todos os demais.

---

O ensinamento do Oráculo

O Oráculo entrega dois mapas para Neo.

O primeiro possui centenas de símbolos.

Setas.

Anotações.

Cores.

Camadas.

O segundo mostra apenas três caminhos.

Neo escolhe imediatamente o segundo.

Ela sorri.

— Por quê?

Neo responde.

— Porque consigo entender para onde estou indo.

Ela coloca a mão sobre seu ombro.

"Um sistema que ninguém compreende deixa de servir às pessoas e passa a exigir que as pessoas sirvam a ele."

---

Lições para um Programador COBOL Padawan

Durante sua carreira você encontrará colegas extremamente inteligentes.

Alguns escreverão soluções impressionantes.

Mas observe atentamente os profissionais realmente admirados após vinte ou trinta anos de experiência.

Quase sempre eles possuem outra característica.

Escrevem programas fáceis de ler.

Escolhem nomes claros.

Criam módulos pequenos.

Documentam decisões.

Eliminam o desnecessário.

Esses profissionais sabem que a manutenção representa a maior parte do ciclo de vida de um software.

Quem simplifica hoje está ajudando um colega — ou a si mesmo — daqui a dez anos.

---

Curiosidades

O princípio KISS influenciou diretamente diversas metodologias modernas:

• Agile, ao priorizar entregas simples e incrementais.

• Extreme Programming (XP), com foco na solução mais simples que funciona.

• YAGNI (You Aren't Gonna Need It), evitando funcionalidades imaginárias.

• Lean Software Development, reduzindo desperdícios.

• Unix Philosophy, que recomenda ferramentas pequenas fazendo uma única tarefa muito bem.

Embora tenham surgido em épocas diferentes, todas compartilham a mesma ideia: simplicidade gera sustentabilidade.

---

Conclusão — O Código Verde da Matrix Era Simples

Quando Neo finalmente enxergou o código verde da Matrix, ele percebeu que por trás de toda aquela realidade existiam padrões claros e elegantes.

Os sistemas mais duradouros seguem exatamente esse caminho.

O princípio KISS nos ensina que complexidade deve existir apenas quando ela é realmente necessária. Cada camada, cada framework, cada abstração e cada linha de código precisam justificar sua existência.

Para um Programador COBOL que trabalha com IBM Z, essa lição é ainda mais valiosa. Sistemas bancários, seguradoras e governos dependem de aplicações que continuarão sendo mantidas por décadas. Quanto mais simples, legíveis e previsíveis forem essas aplicações, maior será sua capacidade de evoluir sem perder confiabilidade.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria escrita na parede da sala do Arquiteto:

"A verdadeira genialidade não está em criar uma Matrix impossível de compreender. Está em construir uma tão simples que qualquer Padawan consiga mantê-la funcionando mesmo cinquenta anos depois."

Porque, no fim, o software que atravessa gerações não é aquele que impressiona pela complexidade.

É aquele que continua resolvendo problemas quando todas as tecnologias da moda já ficaram para trás.