Top 5 na Comunidade Digital Innovation One

Bellacosa Mainframe apresenta a Digital Innovation One

☕ Um Café no Bellacosa Mainframe

Inspetor Bugiganga Entra na DIO: Go-Go-Gadget Developer!

🕵️‍♂️🔧 Bootcamps, cursos, desafios de código, projetos, GitHub, certificados, XP, ranking e aquela estranha sensação de entrar para estudar uma tecnologia e sair querendo aprender outras dez

Existe uma armadilha particularmente perigosa para quem gosta de tecnologia.

Você entra numa plataforma educacional pensando:

“Vou fazer um cursinho.”

Quatro horas depois:

COBOL
 ↓
LINUX
 ↓
GIT
 ↓
PYTHON
 ↓
NODE.JS
 ↓
AWS
 ↓
DOCKER
 ↓
KUBERNETES
 ↓
IA
 ↓
SEGURANÇA
 ↓
MEU DEUS, O QUE ESTOU FAZENDO?

Foi aproximadamente assim que imaginei o Inspetor Bugiganga entrando na Digital Innovation One — DIO.

Ele abre a porta.

Olha para os bootcamps.

Estica um braço mecânico.

Go-Go-Gadget Java!

Outra janela aparece.

Go-Go-Gadget Cloud!

Mais uma.

Go-Go-Gadget Python!

Outra.

Go-Go-Gadget Inteligência Artificial!

Penny observa de longe.

Brain fecha os olhos.

E Dr. Claw provavelmente percebe imediatamente:

“Esse idiota vai matricular-se em tudo.”

Bem-vindo à DIO.

---

🟣 Mas afinal, o que é a DIO?

A Digital Innovation One, conhecida simplesmente como DIO, é uma plataforma de educação tecnológica que construiu seu ecossistema em torno de uma combinação interessante:

CURSOS
+
BOOTCAMPS
+
PROJETOS
+
DESAFIOS
+
CERTIFICADOS
+
COMUNIDADE
+
GAMIFICAÇÃO

Isso muda um pouco a experiência tradicional de estudar tecnologia.

Porque estudar programação normalmente pode ser uma atividade profundamente solitária.

Você.

O computador.

Uma documentação de 847 páginas.

Uma mensagem de erro.

E aquela inevitável pesquisa:

WHY THE HELL IS THIS NOT WORKING

Na DIO existe uma tentativa de transformar essa caminhada em algo mais parecido com uma jornada.

Há progresso.

Há etapas.

Há XP.

Há desafios.

Há projetos.

Há rankings.

Há certificados.

E existe sempre aquela barrinha dizendo:

87%

que produz no cérebro humano uma necessidade quase patológica de chegar a:

100%

Gamificação.

O crack legalizado dos nerds.

---

🕵️ Inspetor Bugiganga recebe sua primeira missão

Chefe Quimby surge misteriosamente dentro de uma máquina de café.

Entrega a mensagem:

SUA MISSÃO:

CONCLUIR O BOOTCAMP
SEM COPIAR O PROJETO
DO INSTRUTOR.

ESTA MENSAGEM
SE AUTODESTRUIRÁ.

Bugiganga lê.

Penny já abriu o GitHub.

Brain está configurando o ambiente.

A mensagem explode na cara do Chefe Quimby.

Tudo normal.

Mas existe aqui uma diferença importante entre assistir a um curso e aprender tecnologia.

Você pode assistir a:

10 horas de Java

e aprender muito pouco.

Pode assistir a:

20 horas de Python

e continuar incapaz de criar sozinho um pequeno programa.

Porque existe uma distância gigantesca entre:

“Eu entendi.”

e:

“Eu consigo fazer.”

A DIO tenta atacar justamente essa distância através dos desafios e projetos.

---

🔧 Go-Go-Gadget Hands-On!

Imagine aprender Git apenas assistindo alguém usar Git.

git init
git add .
git commit
git push

Parece fácil.

Então você tenta sozinho.

fatal:

Ah.

Agora começou a aula verdadeira.

Tecnologia possui uma característica cruel:

ela frequentemente só revela aquilo que você não entendeu quando você tenta fazer sozinho.

Enquanto estamos assistindo ao instrutor:

“Sim.”

“Entendi.”

“Óbvio.”

“Tranquilo.”

Então fechamos o vídeo.

Abrimos o terminal.

_

E o cursor piscando pergunta:

“Então, gênio, por onde começamos?”

Silêncio.

É nesse momento que aprendizado deixa de ser consumo e vira construção.

---

🧠 Penny é a verdadeira desenvolvedora

Quem assistiu ao desenho sabe da verdade.

Inspetor Bugiganga recebe o crédito.

Mas quem resolve grande parte das coisas?

Penny.

Penny investiga.

Penny pesquisa.

Penny utiliza tecnologia.

Penny conecta informações.

Penny encontra o problema.

Brain executa operações de campo que fariam qualquer Red Team pedir orçamento.

Enquanto isso:

Go-Go-Gadget Helicóptero!

Talvez exista aqui uma metáfora perfeita para aprender programação.

O certificado é o Inspetor Bugiganga.

Bonito.

Visível.

Você coloca no LinkedIn.

Mas Penny representa aquilo que realmente interessa:

o conhecimento adquirido durante o caminho.

---

📜 Certificado não compila código

Essa merece destaque.

Você pode possuir:

100 certificados

e ainda assim travar diante de:

Crie uma API REST.

Certificação e certificado possuem valor.

Demonstram esforço.

Criam histórico.

Podem ajudar a organizar aprendizado.

Podem sinalizar interesse profissional.

Mas existe uma pergunta brutal:

Você consegue fazer?

O mercado tecnológico, cedo ou tarde, faz essa pergunta.

Talvez numa entrevista.

Talvez num projeto.

Talvez numa madrugada de produção.

---

🧪 Os desafios de código

Aqui começa a diversão.

Problema:

ENTRADA
 ↓
PROCESSAMENTO
 ↓
SAÍDA ESPERADA

Parece simples.

Até aparecer:

Wrong Answer

Você olha o código.

Está perfeito.

Executa novamente.

Wrong Answer

Você modifica.

Wrong Answer

Consulta documentação.

Wrong Answer

Começa a questionar suas escolhas profissionais.

Então percebe:

espaço adicional na saída

Corrige.

Accepted

Nesse momento ocorre uma pequena descarga de dopamina comparável a derrotar um chefe em videogame.

---

🎮 XP: transformando estudo em RPG

Uma das coisas interessantes do ecossistema DIO é a utilização de elementos de gamificação.

Você estuda.

Conclui atividades.

Avança.

Acumula experiência.

E o cérebro começa a interpretar:

ESTUDAR

como:

EVOLUIR PERSONAGEM

Agora imagine Inspetor Bugiganga.

LEVEL 1
GO-GO-GADGET HTML

Depois:

LEVEL 10
GO-GO-GADGET JAVASCRIPT

Depois:

LEVEL 20
GO-GO-GADGET NODE

Depois:

LEVEL 30
GO-GO-GADGET AWS

Finalmente:

LEVEL 42

Douglas Adams observa do outro lado do universo.

Agora ele encontrou a resposta.

Só falta descobrir a pergunta.

---

🐘 O perigo do buffet tecnológico

Mas existe um problema.

Quando uma plataforma oferece muita coisa interessante, nasce uma criatura perigosa:

o acumulador de cursos.

Ele possui:

17 bootcamps iniciados
43 cursos salvos
28 tecnologias na lista
11 projetos incompletos
97 abas abertas

Conhecimento real:

SELECT *
FROM CEREBRO
WHERE DOMINIO = 'REAL';

Resultado:

0 ROWS RETURNED

Porque existe uma diferença entre explorar e aprender.

---

🕵️ Dr. Claw apresenta o Tutorial Hell

Dr. Claw finalmente revela seu plano maligno.

Não é destruir Bugiganga.

Não é dominar o mundo.

É pior.

Ele prende o desenvolvedor em:

TUTORIAL HELL

O ciclo:

ASSISTE CURSO
     ↓
ENTENDE
     ↓
ASSISTE OUTRO
     ↓
ENTENDE
     ↓
ASSISTE OUTRO
     ↓
ENTENDE
     ↓
TENTA FAZER SOZINHO
     ↓
NÃO CONSEGUE
     ↓
PROCURA OUTRO CURSO

Repita durante cinco anos.

Parabéns.

Você estudou muito.

E construiu quase nada.

---

🛠️ Como escapar?

Professor Penny Bellacosa apresenta a solução:

APRENDER
   ↓
PRATICAR
   ↓
ERRAR
   ↓
DEBUGAR
   ↓
ENTENDER
   ↓
MODIFICAR
   ↓
CONSTRUIR ALGO SEU

O projeto apresentado pelo instrutor deveria ser o começo, não o fim.

Se o curso cria:

API DE LIVROS

faça depois:

API DE FILMES

ou:

API DE CLIENTES

ou:

API DE POKÉMON

ou, naturalmente:

API DE JOBS COBOL QUE DERAM S0C7

Aí começa a aprendizagem real.

---

🦖 E onde entra o velho COBOLzeiro?

Aqui existe uma coisa que considero particularmente interessante.

Plataformas como a DIO são frequentemente associadas à entrada de novos profissionais no mercado.

Mas existe outro público que pode extrair enorme valor delas:

o veterano.

Imagine alguém com décadas de:

COBOL
JCL
CICS
DB2
VSAM
IMS
z/OS

Ele conhece profundamente sistemas empresariais.

Então entra numa trilha de:

Git

Depois:

Python

Depois:

REST APIs

Depois:

Docker

Depois:

Cloud

Depois:

IA

Agora algo interessante acontece.

Ele não deixou de ser mainframe.

Ele criou pontes.

---

🌉 O profissional em T

Existe uma velha ideia sobre profissionais com conhecimento em formato de T.

Horizontal:

────────────────────────────
Git | Cloud | IA | APIs | Linux

Vertical:

          |
          |
        z/OS
          |
        COBOL
          |
        CICS
          |
         Db2
          |
          |

Você possui profundidade numa área.

Mas consegue conversar com várias outras.

Isso é extremamente poderoso.

Especialmente num mundo em que mainframe deixou de ser uma ilha.

Hoje podemos ter:

MOBILE
  ↓
API
  ↓
z/OS CONNECT
  ↓
CICS
  ↓
COBOL
  ↓
DB2

Onde termina “moderno”?

Onde começa “legado”?

Resposta:

ninguém mais sabe.

E talvez essa divisão nem seja tão útil.

---

🔌 Go-Go-Gadget API!

Imagine Bugiganga tentando modernizar um sistema COBOL.

Ele aponta o braço:

Go-Go-Gadget Microservices!

Penny interrompe:

— Não.

Go-Go-Gadget Kubernetes!

— Também não.

Go-Go-Gadget Rewrite Everything!

Penny desliga o braço.

Porque modernização não significa obrigatoriamente substituir.

Às vezes significa:

INTEGRAR

Às vezes:

EXPOR

Às vezes:

AUTOMATIZAR

Às vezes:

TESTAR MELHOR

Às vezes simplesmente:

ENTENDER O QUE JÁ EXISTE.

---

🧠 A DIO como laboratório de curiosidade

Talvez essa seja uma das partes mais interessantes desse tipo de plataforma.

Você entra por uma tecnologia.

E encontra outras.

O programador Java descobre cloud.

O profissional cloud descobre segurança.

O estudante Python descobre IA.

O COBOLzeiro descobre Git.

O desenvolvedor web descobre banco de dados.

E começam conexões inesperadas.

CONHECIMENTO A
       +
CONHECIMENTO B
       =
IDEIA QUE NÃO EXISTIA ANTES

Isso é inovação muito mais frequentemente do que alguma apresentação corporativa com a palavra:

INNOVATION

escrita em fonte 72.

---

🤖 Então chegou a IA

Agora o Inspetor Bugiganga recebeu seu upgrade mais perigoso.

Go-Go-Gadget GPT!

De repente ele consegue:

• explicar código;

• gerar exemplos;

• revisar funções;

• sugerir testes;

• criar documentação;

• explicar mensagens de erro;

• comparar tecnologias;

• ajudar a estruturar projetos.

Fantástico.

Mas Dr. Claw imediatamente percebe a vulnerabilidade.

Se o aluno simplesmente pedir:

“Faça o desafio para mim.”

A IA faz.

O aluno entrega.

Recebe o resultado.

XP aumenta.

Conhecimento:

NULL

Parabéns.

Conseguimos hackear a gamificação.

E derrotar justamente aquilo que estávamos tentando aprender.

---

🧠 IA como Penny, não como piloto automático

A melhor utilização educacional de IA talvez seja tratá-la como Penny.

Pergunte:

“Explique por que isto está errado.”

Melhor que:

“Resolva.”

Pergunte:

“Dê uma pista.”

Pergunte:

“Mostre outro exemplo.”

Pergunte:

“Compare minha solução com outra abordagem.”

Pergunte:

“Crie cinco testes que possam quebrar meu código.”

Agora a IA não substitui o exercício.

Ela aumenta o exercício.

Essa diferença será cada vez mais importante.

---

📂 GitHub: onde o corpo fica enterrado

O certificado diz:

CONCLUÍ O BOOTCAMP

O GitHub pode mostrar:

O QUE EU FIZ

Existe uma diferença poderosa.

Projetos permitem construir evidência.

README.

Commits.

Código.

Testes.

Documentação.

Evolução.

Você começa com:

projeto-final

Depois:

projeto-final-v2

Depois:

agora-vai

Depois:

agora-vai-final

Depois:

agora-vai-final-definitivo

Depois:

agora-vai-final-definitivo-2

Todo desenvolvedor já passou por essa fase antes de compreender Git.

Não negue.

---

🏆 Ranking é divertido — mas existe um chefe secreto

XP é divertido.

Ranking é divertido.

Badges são divertidos.

Certificados são divertidos.

Mas existe um boss escondido no final:

AUTONOMIA.

O momento em que você abre uma tela vazia e consegue começar.

Sem instrutor.

Sem copiar repositório.

Sem vídeo mostrando exatamente o próximo passo.

Você pensa:

PRECISO FAZER X.

Então divide:

X
├── A
├── B
├── C
└── D

Pesquisa aquilo que não conhece.

Experimenta.

Erra.

Corrige.

Entrega.

Quando chega nesse ponto, algo mudou.

Você deixou de apenas estudar tecnologia.

Começou a trabalhar com tecnologia.

---

🕵️ Chefe Quimby entrega a missão final

Mensagem:

MISSÃO FINAL

ESCOLHA UMA TECNOLOGIA.

APRENDA O FUNDAMENTO.

CONCLUA O CURSO.

FAÇA O DESAFIO.

TERMINE O PROJETO.

DEPOIS FECHE O CURSO.

ABRA UMA TELA VAZIA.

E FAÇA OUTRA COISA
SEM O INSTRUTOR.

Bugiganga lê.

Penny sorri.

Brain coloca o capacete.

A mensagem explode novamente na cara do Chefe Quimby.

Naturalmente.

---

☕ O verdadeiro XP

Existe uma tentação moderna de transformar educação em números.

HORAS
CERTIFICADOS
BADGES
XP
RANKING
CURSOS

Todos podem ser úteis.

Todos podem motivar.

Todos podem mostrar progresso.

Mas existe uma métrica invisível muito mais interessante:

quantas coisas você consegue fazer hoje que não conseguia fazer seis meses atrás?

Essa é difícil de colocar num dashboard.

Mas é provavelmente a mais importante.

---

🦖 O mainframe encontra a DIO

Talvez alguém olhe para um veterano de mainframe estudando Node.js, Python, cloud, IA ou segurança e pergunte:

“Você vai abandonar COBOL?”

Não necessariamente.

Talvez esteja fazendo exatamente o contrário.

Está aumentando o raio de ação.

Ontem:

COBOL

Hoje:

COBOL
+
GIT
+
APIs
+
CLOUD
+
PYTHON
+
IA

A experiência antiga não desapareceu.

Ela ganhou novas interfaces.

O dinossauro não morreu.

Instalaram foguetes nele.

---

🚀 Go-Go-Gadget Developer!

E talvez essa seja a melhor imagem para representar a jornada.

Inspetor Bugiganga começa cheio de ferramentas.

Algumas ele domina.

Outras não.

Algumas funcionam.

Outras explodem.

Algumas resolvem problemas.

Outras criam problemas maravilhosamente maiores.

Mas ele continua avançando.

Quem trabalha com tecnologia conhece perfeitamente essa sensação.

Porque ninguém sabe tudo.

O desenvolvedor experiente não é aquele que possui todas as respostas.

É aquele que aprendeu a fazer uma coisa muito mais importante:

descobrir a próxima resposta.

---

☕ Epílogo — Um Café no Bellacosa Mainframe

02:13 da manhã.

O bootcamp marca:

99%

Existe apenas um desafio restante.

Inspetor Bugiganga olha para a tela.

Penny já sabe a solução.

Brain está dormindo embaixo da mesa.

Dr. Claw observa através de seu monitor.

“Desista, Gadget.”

Bugiganga abre o editor.

Executa.

Wrong Answer

Modifica.

Wrong Answer

Modifica novamente.

Runtime Error

Respira.

Toma café.

Lê o problema outra vez.

Encontra uma condição que havia ignorado.

Corrige.

Executa.

Accepted

A tela muda:

BOOTCAMP
████████████████████ 100%

CONCLUÍDO

Ele levanta os braços.

GO-GO-GADGET CERTIFICADO!

Penny olha para ele.

— Agora faça novamente sem olhar a solução.

Silêncio.

Bugiganga lentamente volta a sentar.

Fecha o projeto.

Cria uma pasta vazia.

novo-projeto/

O cursor começa a piscar.

E talvez seja exatamente ali...

não no certificado,

não no XP,

não no ranking,

mas diante daquela tela completamente vazia...

que começa o verdadeiro desenvolvedor.

☕🕵️‍♂️🔧🦖

GO-GO-GADGET LEARNING.

Porque em tecnologia o curso pode terminar.

O aprendizado nunca dá MAXCC=0000.

https://web.dio.me

https://web.dio.me/users/vagnerbellacosa

https://www.dio.me/sign-up?ref=AF7UPRJR3CU1

https://eljefemidnightlunch.blogspot.com/2026/06/reconhecimento-pelos-5-anos-no-dio.html

Ontem foi um dia muito feliz, fui surpreendido com uma carta, ao abri-la foi muita emoção, ser reconhecido pelos meus pares, dentre uma comunidade de 700 k, parceiros, mestres jedi, padawans e renegado. Sempre aprendendo e divertindo-se no percurso, muito obrigado família @digitalinnovation.one

 

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.