Backlog: O Dataset Invisível que Pode Salvar ou Destruir um Projeto Mainframe

 

Bellacosa Mainframe e o conceito do backlog na stack mainframe

☕ Um Café no Bellacosa Mainframe

Backlog: O Dataset Invisível que Pode Salvar ou Destruir um Projeto Mainframe

"No mundo IBM Z, um programa COBOL raramente quebra por causa de uma linha de código. Quase sempre ele quebra porque existe um backlog que ninguém quis enxergar."

Existe uma palavra que todo profissional de TI escuta diariamente: Backlog.

Ela aparece em reuniões ágeis, em SCRUM, em Kanban, nos relatórios do gerente, nos dashboards do Jira e até em apresentações do CIO.

Mas curiosamente, poucos programadores COBOL entendem o verdadeiro significado do backlog.

Para um Padawan Mainframe, backlog costuma parecer apenas uma lista enorme de tarefas.

Na realidade, backlog é muito mais parecido com um dataset VSAM KSDS.

Ele armazena tudo que ainda precisa ser processado.

Se ele estiver organizado, o sistema flui.

Se estiver corrompido...

Você acabou de criar o próximo ABEND da equipe.

---

Imagine um Batch Noturno

Pense em um JOB executando durante a madrugada.

Ele possui:

• milhares de registros

• prioridades

• dependências

• checkpoints

• reprocessamentos

Agora substitua os registros por atividades.

Pronto.

Você acabou de entender o backlog.

O backlog é simplesmente o conjunto de trabalho que ainda será executado.

Mas existe uma diferença enorme entre:

muito trabalho

e

backlog saudável.

---

O Backlog Não É o Problema

O backlog é inevitável.

Todo sistema vivo possui backlog.

Até o z/OS trabalha com filas.

JES2 possui filas.

CICS possui filas.

MQ possui filas.

IMS possui filas.

DB2 possui locks esperando.

Tudo funciona através de filas.

O problema nunca foi possuir backlog.

O problema é possuir um backlog que ninguém entende.

---

Como Nasce um Backlog

Imagine um sistema bancário.

Hoje o gerente pede:

Criar PIX.

Depois:

alterar TED.

Depois:

corrigir boleto.

Depois:

adequação ao Banco Central.

Depois:

LGPD.

Depois:

Open Finance.

Depois:

PIX Automático.

Depois:

IA.

Depois:

APIs REST.

Cada solicitação entra.

Nem todas saem.

O resultado?

Um backlog crescente.

---

O Backlog Invisível

O pior backlog é o invisível.

Ele mora em frases como:

"Depois a gente vê."

"Na próxima Sprint."

"Isso fica para outro momento."

"É uma melhoria."

"Não é urgente."

Meses depois...

Existem centenas delas.

---

Backlog Técnico

Nem todo backlog é funcional.

Existe também:

• melhoria de performance

• reorganização de programas

• limpeza de código

• documentação

• atualização de COPYBOOKS

• reorganização DB2

• índices

• compressão VSAM

• testes

Tudo isso entra no backlog.

---

Como Identificar um Backlog Doente

Um backlog começa a adoecer quando aparecem sintomas.

Sintoma 1

Todo mundo pergunta:

"O que devemos fazer agora?"

Isso significa ausência de prioridade.

---

Sintoma 2

Existem tarefas de três anos atrás.

Se ninguém fez em três anos...

Talvez nunca devesse existir.

---

Sintoma 3

Existem tarefas duplicadas.

Muito comum.

Um analista abre:

"Corrigir cálculo."

Outro abre:

"Ajustar juros."

Outro:

"Problema financeiro."

São o mesmo erro.

---

Sintoma 4

Ninguém sabe explicar a tarefa.

Descrição:

"Verificar erro."

Qual erro?

Onde?

Quando?

Por quê?

---

Sintoma 5

Todo item é prioridade máxima.

Quando tudo é urgente...

Nada é urgente.

---

Como um Programador COBOL Deve Ler um Backlog

Nunca leia apenas o título.

Leia:

• requisito

• regra de negócio

• programas envolvidos

• COPYBOOKS

• arquivos

• tabelas DB2

• transações CICS

• JCL

• impacto

A tarefa começa muito antes do código.

---

O Erro do Padawan

O Padawan pensa:

"Recebi uma tarefa."

O profissional experiente pensa:

"Recebi um problema de negócio."

Isso muda tudo.

---

Como Evoluir um Backlog

Existe uma prática chamada:

Backlog Refinement

Ou refinamento.

No Mainframe isso seria parecido com preparar um JOB antes da produção.

Você elimina ambiguidades.

---

Durante o refinamento fazemos perguntas.

O usuário realmente quer isso?

Existe impacto financeiro?

Existe impacto jurídico?

Existe cálculo?

Existe histórico?

Existe rollback?

Existe auditoria?

Existe logging?

Existe batch?

Existe online?

Existe integração?

---

Quanto mais perguntas...

Menor o risco.

---

Um Backlog Não Deve Crescer Para Sempre

Imagine um dataset.

Se ninguém fizer housekeeping...

Ele cresce.

Depois cresce.

Depois cresce.

Depois o volume explode.

Depois aparece:

SPACE ABEND

O backlog também.

---

Como Priorizar

Uma técnica simples.

Divida em quatro grupos.

Incêndio

Sistema parado.

---

Financeiro

Pode gerar prejuízo.

---

Cliente

Afeta usuários.

---

Melhoria

Pode esperar.

---

A maioria dos times mistura tudo.

---

Backlog e COBOL

Um programa COBOL raramente possui apenas uma alteração.

Quando você abre um fonte...

Encontra:

Alteração 2003

Alteração 2006

Alteração 2009

Alteração 2014

Alteração 2018

Alteração 2021

Alteração 2025

Cada comentário representa um backlog encerrado.

O código conta a história da empresa.

---

O Backlog Bom

Possui:

✔ descrição

✔ prioridade

✔ responsável

✔ impacto

✔ dependência

✔ prazo

✔ critério de aceite

✔ documentação

---

O Backlog Ruim

Descrição:

"Ajustar."

Boa sorte.

---

A Grande Diferença Entre Backlog e Dívida Técnica

Muita gente mistura.

Mas são conceitos completamente diferentes.

Backlog

É trabalho conhecido.

Sabemos que precisa ser feito.

Está registrado.

Está visível.

Pode ser priorizado.

---

Dívida Técnica

É trabalho escondido.

Você decidiu fazer algo mais rápido.

Agora pagará juros.

---

Imagine um empréstimo.

Você compra uma casa.

Ainda deve dinheiro.

A casa existe.

Mas existe dívida.

No software é igual.

---

Exemplo.

Você precisava entregar uma alteração.

O correto seria:

• modularizar

• criar testes

• atualizar documentação

Mas o prazo era curto.

Você fez um IF gigantesco.

Funcionou.

Pronto.

Nasceu uma dívida técnica.

---

Backlog Pode Não Ser Dívida

Exemplo.

Nova funcionalidade PIX.

Ela nunca existiu.

Está no backlog.

Não existe dívida.

É apenas trabalho futuro.

---

Dívida Técnica Pode Não Estar no Backlog

Muito comum.

Todo mundo sabe que existe.

Ninguém registra.

Ninguém fala.

Até o dia em que explode.

---

Como Identificar Dívida Técnica

Pergunte:

"Se eu tivesse mais tempo...

faria diferente?"

Se a resposta for SIM...

Existe dívida técnica.

---

Os Juros da Dívida Técnica

Assim como um banco cobra juros...

O software também.

Cada alteração demora mais.

Cada teste demora mais.

Cada deploy gera medo.

Cada manutenção aumenta.

---

Dívida Técnica no Mainframe

Exemplos.

Programa COBOL com:

12000 linhas.

Sem PERFORM.

GO TO para todos os lados.

COPYBOOK repetido.

Campos duplicados.

Comentários de 1998.

Variáveis mortas.

Parágrafos nunca chamados.

SQL repetido.

MOVE desnecessário.

PERFORM THROUGH gigantesco.

Tudo isso gera dívida.

---

Como Corrigir

Nunca tente pagar toda a dívida de uma vez.

Faça igual um financiamento.

Pague parcelas.

Sempre que alterar um programa:

melhore um pouco.

Renomeie variáveis.

Remova código morto.

Atualize comentários.

Crie testes.

Melhore SQL.

Refatore pequenos blocos.

---

A Regra do Escoteiro

Robert C. Martin criou uma regra famosa.

Deixe o código melhor do que encontrou.

No Mainframe ela é perfeita.

---

Backlog Funcional

Pedido do negócio.

---

Backlog Técnico

Pedido da TI.

---

Backlog Arquitetural

Mudanças estruturais.

Exemplos.

Migrar VSAM.

Migrar CICS.

Atualizar COBOL.

Atualizar compilador.

Migrar DB2.

Atualizar RACF.

---

O Backlog Nunca Acaba

Isso assusta iniciantes.

Mas é normal.

Software vivo nunca termina.

Ele evolui.

---

Curiosidade Mainframe nº 1

Nos anos 70 ninguém dizia "Backlog".

Chamavam de:

Pending Requests

Programming Queue

Change Queue

Maintenance Queue

A palavra backlog ficou popular muito depois com métodos ágeis.

---

Curiosidade nº 2

Em muitos bancos brasileiros ainda existem planilhas Excel paralelas ao Jira.

Sim.

O backlog oficial nem sempre é o verdadeiro.

---

Curiosidade nº 3

Algumas empresas possuem backlog maior que o código.

Há milhares de demandas abertas.

Mas apenas algumas centenas realmente serão desenvolvidas.

---

Curiosidade nº 4

O maior inimigo do backlog não é a falta de programadores.

É a falta de decisão.

---

Curiosidade nº 5

Muitos ABENDs históricos aconteceram porque uma melhoria pequena ficou anos esquecida.

Quando finalmente foi feita...

Ninguém mais entendia o motivo original.

---

Easter Egg IBM Z

Você já percebeu?

O JES2 organiza trabalhos.

O MQ organiza mensagens.

O CICS organiza transações.

O DB2 organiza dados.

O RACF organiza permissões.

O backlog organiza pessoas.

No fundo...

Todo o ecossistema IBM Z é baseado em gerenciamento de filas.

---

Easter Egg COBOL

O comando:

NEXT SENTENCE

parece simples.

Mas ele simboliza exatamente muitos backlogs.

Você pula para frente sem realmente resolver o problema.

Funciona.

Até deixar de funcionar.

---

Easter Egg DB2

Um índice mal planejado gera consultas lentas.

Um backlog mal priorizado gera equipes lentas.

Os dois possuem exatamente o mesmo problema:

falta de organização.

---

Easter Egg CICS

Em CICS existe o conceito de resposta rápida.

O usuário não pode esperar.

No backlog também.

Quanto mais tempo uma tarefa fica parada...

Maior a chance de perder contexto.

---

Easter Egg JCL

Imagine um JOB.

STEP010

STEP020

STEP030

STEP040

Existe ordem.

Existe dependência.

Existe fluxo.

Um backlog deveria funcionar exatamente assim.

---

Easter Egg VSAM

Um KSDS desorganizado sofre mais splits.

Uma equipe desorganizada sofre mais interrupções.

---

Easter Egg RACF

No RACF, tudo segue o princípio do menor privilégio.

No backlog, vale um princípio parecido:

o menor item possível.

Histórias pequenas fluem melhor do que demandas gigantescas.

---

O Conselho Final para Todo Padawan COBOL

Quando você entrar em um projeto Mainframe, não olhe apenas para o código-fonte. Observe a saúde do backlog. Um programa de 30 anos pode ser surpreendentemente fácil de manter se houver um backlog bem organizado, prioridades claras e comunicação constante entre negócio e tecnologia. Por outro lado, um sistema moderno pode se tornar um pesadelo quando acumula tarefas mal descritas, prioridades conflitantes e dívida técnica ignorada.

Aprenda a fazer perguntas antes de programar. Entenda a regra de negócio antes de abrir o editor COBOL. Documente suas descobertas, refine as histórias, questione requisitos ambíguos e aproveite cada manutenção para deixar o código um pouco melhor do que estava. Essa disciplina, repetida diariamente, transforma um Padawan em um verdadeiro Mestre Mainframe.

No universo IBM Z, backlog é o mapa da jornada, enquanto a dívida técnica é o peso que você carrega na mochila. O mapa pode crescer à medida que novos caminhos surgem, mas o peso só aumenta quando atalhos mal planejados são tomados. Os melhores profissionais aprendem a equilibrar os dois: mantêm um backlog claro, vivo e priorizado, enquanto pagam pequenas parcelas da dívida técnica a cada entrega.

No fim das contas, a maior lição é simples: software não é apenas código; é uma fila contínua de decisões. Assim como o JES2 coordena jobs, o CICS gerencia transações e o DB2 organiza dados, um bom desenvolvedor organiza seu trabalho, seu conhecimento e sua evolução. É essa capacidade de transformar caos em ordem que diferencia um programador que apenas entrega tarefas de um engenheiro que constrói sistemas capazes de sobreviver por décadas — exatamente como os grandes ambientes IBM Z que continuam sustentando bancos, seguradoras, governos e empresas em todo o mundo.

RAD (Rapid Application Development) - O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia RAD Parte I

 

Bellacosa Mainframe apresenta a rapid application development parte i

☕ Um Café no Bellacosa Mainframe

RAD (Rapid Application Development)

O Que Todo Programador COBOL Precisa Saber Sobre a Metodologia que Ensinou o Mundo a Desenvolver Software Rapidamente

Você Não Está Descobrindo uma Ideia Nova. Está Descobrindo uma Tecnologia que Influenciou Quase Tudo o Que Veio Depois.

"Toda geração acredita que inventou uma forma mais rápida de desenvolver software. Poucos percebem que muitas dessas ideias nasceram há mais de trinta anos. O RAD foi uma delas."

---

Introdução

Quem começou a trabalhar com desenvolvimento de software nos anos 80 e 90 certamente ouviu falar de uma promessa bastante ousada.

"Vamos desenvolver sistemas em poucos meses."

Naquela época isso parecia impossível.

O desenvolvimento tradicional era lento.

Primeiro vinha o levantamento de requisitos.

Depois a documentação.

Depois o projeto.

Depois a programação.

Depois os testes.

Depois a homologação.

E finalmente... meses ou anos depois... o usuário via o sistema funcionando.

Não era raro um projeto durar dois ou três anos.

O problema?

Quando finalmente ficava pronto, o negócio já havia mudado.

As regras eram outras.

As necessidades eram diferentes.

E boa parte do software já nascia desatualizada.

Foi justamente para resolver esse problema que surgiu o Rapid Application Development, mais conhecido como RAD.

Muitos desenvolvedores mais jovens imaginam que desenvolvimento rápido começou com Agile, Scrum, DevOps, Low-Code ou Inteligência Artificial.

Na verdade, todos esses movimentos herdaram conceitos que o RAD apresentou décadas antes.

Para quem trabalha com COBOL, isso é especialmente interessante.

Durante muito tempo criou-se o mito de que Mainframe significa desenvolvimento lento.

Na prática, diversos bancos brasileiros entregavam sistemas críticos em velocidade impressionante utilizando conceitos extremamente próximos do RAD, mesmo antes de adotarem oficialmente essa metodologia.

O segredo nunca foi apenas a linguagem.

O segredo sempre foi o processo.

---

O cenário antes do RAD

Para entender o RAD precisamos voltar aos anos 1980.

A informática corporativa vivia um momento curioso.

Os computadores estavam ficando mais poderosos.

As empresas dependiam cada vez mais dos sistemas.

Mas o desenvolvimento continuava extremamente burocrático.

O modelo dominante era o famoso Waterfall, ou Cascata.

Sua lógica era simples.

Primeiro termina uma fase.

Depois começa a próxima.

Jamais volte atrás.

Na teoria fazia sentido.

Na prática...

Nem tanto.

Imagine desenvolver um sistema bancário durante dezoito meses.

Durante esse período:

• novas leis aparecem;

• novos produtos financeiros surgem;

• a inflação muda;

• concorrentes inovam;

• clientes mudam de comportamento.

Quando o software finalmente chega à produção...

Ele resolve um problema que talvez nem exista mais.

Era uma época em que modificar requisitos era quase um pecado.

Qualquer alteração significava:

• alterar documentos;

• alterar diagramas;

• alterar especificações;

• alterar programas;

• alterar testes.

Tudo isso custava muito dinheiro.

Foi nesse ambiente que algumas pessoas começaram a fazer uma pergunta aparentemente simples.

"E se desenvolvêssemos junto com o usuário?"

Essa pergunta mudaria a história da Engenharia de Software.

---

O nascimento do RAD

O principal responsável pela popularização do RAD foi James Martin.

James Martin era um dos maiores especialistas em Engenharia de Software da época.

Consultor.

Autor.

Pesquisador.

Visionário.

Em 1991 publicou um livro que se tornaria referência mundial:

Rapid Application Development.

Naquele momento ele propôs algo bastante diferente.

Ao invés de gastar meses planejando cada detalhe do sistema...

Construa uma primeira versão.

Mostre ao usuário.

Receba feedback.

Melhore.

Repita.

Hoje isso parece absolutamente normal.

Na época era revolucionário.

Martin defendia que o software não deveria nascer perfeito.

Deveria nascer útil.

Existe uma enorme diferença entre essas duas ideias.

---

O grande problema que o RAD resolveu

Imagine um gerente de banco.

Ele pede um sistema.

Durante meses responde entrevistas.

Participa de reuniões.

Assina documentos.

Depois desaparece.

Um ano depois recebe o software.

Ao abrir a aplicação percebe algo curioso.

"Não era exatamente isso que eu queria."

Essa frase custava milhões de dólares.

Não porque os programadores eram ruins.

Mas porque pessoas têm dificuldade em imaginar um sistema apenas olhando documentação.

Quando veem uma tela funcionando...

Tudo muda.

Elas descobrem novas necessidades.

Percebem erros.

Lembram regras esquecidas.

Propõem melhorias.

O RAD transformou essa descoberta em metodologia.

Em vez de lutar contra mudanças...

Passe a utilizá-las como parte natural do desenvolvimento.

---

O princípio mais importante do RAD

Se fosse necessário resumir o RAD em apenas uma frase, seria esta:

O usuário entende melhor um sistema funcionando do que um documento descrevendo esse sistema.

Esse conceito parece óbvio hoje.

Mas revolucionou a forma de desenvolver software.

Em vez de produzir centenas de páginas de documentação...

Construa rapidamente um protótipo.

Mesmo incompleto.

Mesmo simples.

Mesmo temporário.

Porque um protótipo gera discussões muito mais produtivas do que um documento.

É muito mais fácil dizer:

"Esse botão deveria estar aqui."

Do que imaginar onde ele deveria ficar lendo uma especificação técnica.

---

O que significa "Rapid"

Muita gente interpreta o nome errado.

Rapid não significa:

"Programar correndo."

Nem:

"Escrever código sem qualidade."

Nem:

"Ignorar documentação."

Nem:

"Fazer gambiarra."

Rapid significa reduzir desperdícios.

Eliminar atividades que não agregam valor.

Descobrir erros cedo.

Corrigir rapidamente.

Automatizar tarefas repetitivas.

Construir somente aquilo que realmente será utilizado.

Em outras palavras...

Ser rápido porque o processo ficou melhor.

Não porque os programadores trabalham mais horas.

---

Os quatro pilares do RAD

Embora existam diversas interpretações, praticamente todas compartilham quatro fundamentos.

1. Desenvolvimento iterativo

Ao invés de entregar tudo no final...

Entregue pequenas partes continuamente.

Cada versão adiciona funcionalidades.

Cada ciclo reduz riscos.

Cada entrega aproxima o produto da necessidade real.

Esse conceito mais tarde inspiraria boa parte do Agile.

---

2. Prototipação

O protótipo é talvez a característica mais conhecida do RAD.

Ele não precisa ser bonito.

Nem completo.

Seu objetivo é validar ideias.

Quanto antes o usuário interagir...

Melhor.

Hoje fazemos isso com wireframes.

Mockups.

Aplicações Low-Code.

Ferramentas de UX.

Nos anos 90 isso já existia, apenas com tecnologias diferentes.

---

3. Participação intensa do usuário

No RAD o cliente deixa de ser apenas aprovador.

Ele participa continuamente.

Isso reduz um problema clássico.

Desenvolver exatamente aquilo que ninguém precisava.

Quanto mais próximo estiver o usuário...

Maior a chance de sucesso.

---

4. Times pequenos e multidisciplinares

Equipes enormes costumam gerar burocracia.

RAD prefere grupos pequenos.

Com autonomia.

Decisão rápida.

Comunicação simples.

Responsabilidade compartilhada.

Décadas depois...

Scrum repetiria praticamente o mesmo conceito.

---

O ciclo de vida do RAD

Embora existam variações, normalmente encontramos quatro grandes fases.

Planejamento

Define objetivos.

Escopo inicial.

Equipe.

Restrições.

Não tenta prever absolutamente tudo.

Planeja apenas o suficiente para começar.

---

Design colaborativo

Usuários e desenvolvedores trabalham juntos.

Modelam processos.

Criam protótipos.

Validam telas.

Ajustam regras.

É uma fase extremamente dinâmica.

---

Construção rápida

Os desenvolvedores começam imediatamente.

Ferramentas de geração automática.

Componentes reutilizáveis.

Bibliotecas.

Frameworks.

Tudo é utilizado para acelerar o trabalho.

---

Transição

Depois das validações...

O sistema entra em produção.

Mas o ciclo continua.

Novas versões aparecem.

Novos ajustes são realizados.

O software evolui continuamente.

---

RAD e Engenharia de Software

Existe um mito curioso.

Algumas pessoas acreditam que RAD significa abandonar Engenharia de Software.

Na verdade ocorre exatamente o contrário.

O RAD depende fortemente de boas práticas.

Arquitetura.

Modelagem.

Reutilização.

Padronização.

Automação.

Sem isso...

O desenvolvimento rápido se transforma rapidamente em caos.

Quanto maior a velocidade...

Maior deve ser a disciplina.

---

RAD versus Waterfall

A comparação mais comum é entre RAD e Cascata.

Waterfall	RAD
Planejamento extenso	Planejamento suficiente
Documentação pesada	Protótipos
Entrega única	Entregas frequentes
Mudanças caras	Mudanças esperadas
Usuário distante	Usuário presente
Descobre erros tarde	Descobre erros cedo

Nenhum modelo é perfeito.

Projetos extremamente regulados ainda utilizam Cascata.

Projetos inovadores normalmente preferem abordagens iterativas.

---

O RAD influenciou quase tudo

É curioso observar quantas metodologias modernas possuem DNA do RAD.

Scrum utiliza iterações.

Kanban utiliza fluxo contínuo.

Lean elimina desperdícios.

XP incentiva feedback constante.

DevOps aproxima desenvolvimento e operação.

Low-Code acelera construção.

No-Code reduz codificação.

IA Generativa cria protótipos em minutos.

Nenhuma dessas ideias nasceu isoladamente.

Todas beberam, em maior ou menor grau, da mesma fonte: a busca por ciclos curtos de entrega e validação.

---

Vantagens do RAD

Para o negócio, os benefícios são claros:

• redução do tempo de entrega;

• menor custo de mudanças;

• maior participação do cliente;

• melhor alinhamento com o negócio;

• menor risco de desenvolver funcionalidades desnecessárias;

• maior satisfação dos usuários;

• retorno mais rápido do investimento;

• possibilidade de corrigir erros antes que se tornem caros.

Para os desenvolvedores, o ganho também é significativo.

Ver o sistema funcionando cedo aumenta a motivação da equipe.

O feedback deixa de ser uma surpresa no final do projeto e passa a orientar o trabalho desde o primeiro ciclo.

---

Desvantagens e limitações

Nenhuma metodologia resolve todos os problemas.

O RAD também possui limitações.

Projetos gigantescos, envolvendo centenas de equipes e forte dependência regulatória, podem exigir maior formalismo.

Além disso, o sucesso depende da disponibilidade do usuário.

Se o cliente não participa, o principal benefício do RAD desaparece.

Outro ponto crítico é a arquitetura.

A pressa para entregar não pode comprometer a qualidade estrutural da solução.

Sem uma boa arquitetura, cada nova iteração aumenta a dívida técnica.

---

Mitos sobre o RAD

Ao longo dos anos, alguns equívocos se tornaram comuns.

"RAD é programar sem planejamento."
Não. O planejamento existe, mas é adaptativo.

"RAD elimina documentação."
Não. Ele elimina documentação desnecessária.

"RAD serve apenas para sistemas pequenos."
Não. Grandes organizações o utilizam, desde que combinado com boa governança.

"RAD gera software de baixa qualidade."
Também não. Quando bem aplicado, tende a produzir software mais aderente às necessidades do negócio justamente porque recebe feedback constante.

---

O que um programador COBOL deve aprender com o RAD?

Talvez a maior lição do RAD seja esta:

A velocidade de um projeto não depende apenas da linguagem.

COBOL continua processando bilhões de transações diariamente com confiabilidade incomparável.

O desafio moderno não é substituir COBOL, mas reduzir o tempo entre uma ideia de negócio e sua implementação em produção.

É aí que entram os princípios do RAD.

Prototipação.

Integração contínua.

Automação de testes.

Reutilização de componentes.

Participação ativa do usuário.

Entrega incremental.

Esses conceitos funcionam tão bem em aplicações web quanto em ambientes IBM Z.

Um programa COBOL que expõe serviços por meio do z/OS Connect, integra APIs REST, participa de pipelines DevOps e recebe feedback frequente do negócio está muito mais próximo do espírito do RAD do que muitos sistemas escritos com tecnologias consideradas "modernas".

No fim, o RAD nunca foi sobre velocidade pela velocidade.

Sempre foi sobre reduzir desperdícios, aprender mais cedo e entregar valor continuamente.

Essa ideia nasceu há mais de três décadas, atravessou gerações de linguagens, frameworks e plataformas, e continua moldando a forma como construímos software.

No próximo café, veremos como colocar o RAD em prática: metodologias, ferramentas clássicas e modernas, métricas, governança, performance, integração com Low-Code, IA e um passo a passo completo para implementar RAD com sucesso — inclusive em ambientes IBM Mainframe.

Agile sem Mistérios no IBM Z : O Guia Definitivo do Programador COBOL Padawan para Sobreviver ao Mundo Ágil sem Esquecer as Lições da Tela Verd

 

Bellacosa Mainframe agile sem misterios no ibm z

☕ Um Café no Bellacosa Mainframe

Agile sem Mistérios no IBM Z

O Guia Definitivo do Programador COBOL Padawan para Sobreviver ao Mundo Ágil sem Esquecer as Lições da Tela Verde

"Um Jedi não luta contra a mudança. Ele aprende a usá-la a seu favor."

Existe um momento na vida de praticamente todo programador COBOL em que alguém entra na sala e anuncia:

"A partir da próxima semana vamos trabalhar em Agile."

Imediatamente surgem dezenas de pensamentos.

"Mas COBOL não é batch?"

"Como fazer Sprint se meu programa roda quatro horas?"

"Quem inventou Daily Meeting?"

"O Product Owner entende o que é um SQLCODE -904?"

"Como colocar DevOps num ambiente onde existe Change Management, CAB, RACF, CICS, Db2, IMS e três ambientes de homologação?"

Respire.

A boa notícia é que praticamente todos os grandes bancos do planeta trabalham hoje utilizando alguma adaptação de Agile sobre IBM Z.

Na verdade...

Existe uma ironia curiosa.

O mainframe já fazia diversas coisas "ágeis" muito antes do Manifesto Ágil existir.

Vamos descobrir por quê.

---

A Grande Mentira Sobre Agile

Muitos iniciantes acreditam que Agile significa:

trabalhar rápido.

Não.

Outros acreditam que significa:

fazer reuniões.

Também não.

Outros imaginam:

não existe documentação.

Errado novamente.

Agile significa algo muito mais simples.

Reduzir o custo da mudança.

Essa é a verdadeira definição.

Quanto mais cedo você descobrir um erro...

...mais barato ele fica.

---

O Mundo Antes do Agile

Imagine desenvolver um sistema bancário em 1988.

O fluxo era mais ou menos assim:

Levantamento

↓

Análise

↓

Especificação

↓

Projeto

↓

Programação

↓

Testes

↓

Homologação

↓

Produção

Tudo parecia organizado.

O problema?

O cliente só via o sistema depois de um ano.

Quando via...

Descobria que queria outra coisa.

Dinheiro perdido.

---

O Manifesto Ágil

Em 2001, dezessete especialistas reuniram-se nas montanhas de Utah.

Eles perceberam algo curioso.

Os projetos que davam certo...

...quase nunca seguiam o processo enorme definido nos livros.

Então criaram quatro valores famosos.

Pessoas acima de processos.

Software funcionando acima de documentos gigantes.

Colaboração acima de contratos.

Adaptabilidade acima de seguir planos cegamente.

Observe.

Eles nunca disseram que documentação é ruim.

Disseram apenas que ela não pode ser mais importante que entregar valor.

---

O IBM Z Sempre Foi Mais Ágil do Que Parece

Aqui vem um dos primeiros easter eggs.

Muito antes do Scrum existir...

o operador de produção já fazia ciclos extremamente curtos.

Imagine.

Executa Job

↓

Analisa JESMSGLG

↓

Corrige JCL

↓

Executa novamente

Isso é um loop.

Agile adora loops.

---

Outro exemplo.

Compile

↓

Linkedit

↓

Teste

↓

Erro

↓

Corrige

↓

Compile novamente

Outro Sprint.

Sem ninguém perceber.

---

O Backlog no Mainframe

Imagine um banco.

Backlog:

Novo PIX

Nova TED

Mudança no boleto

Correção fiscal

Nova regra do BACEN

Mudança LGPD

Novo relatório

Integração Open Finance

Atualização cambial

Tudo isso entra numa única fila.

Essa fila é o Product Backlog.

Ela muda diariamente.

---

Quem Decide?

No mundo COBOL existe uma figura curiosa.

O usuário de negócio.

Ele normalmente conhece:

• contas

• empréstimos

• cartões

• seguros

Mas talvez nunca tenha ouvido falar em:

DSNHLI

SQLCA

RACF

IMS

CICS

VSAM KSDS

É exatamente por isso que existe o Product Owner.

Ele traduz o negócio.

Você traduz tecnologia.

---

Sprint

Agora imagine um Sprint de duas semanas.

Objetivo:

Permitir PIX Agendado.

Não é:

Modificar programa COBOL.

Observe a diferença.

O Sprint entrega valor.

Não código.

---

O Trabalho do Padawan COBOL

Durante o Sprint você pode receber tarefas como:

Modificar programa COBOL.

Criar novo COPYBOOK.

Alterar tabela Db2.

Criar PACKAGE.

Executar BIND.

Modificar CICS.

Atualizar MQ.

Criar API via z/OS Connect.

Tudo isso pertence ao mesmo Sprint.

---

A Daily Meeting

Aqui nasce uma das maiores lendas do Agile.

A Daily NÃO existe para o gerente descobrir quem trabalhou.

Ela serve para sincronizar conhecimento.

Imagine dez desenvolvedores.

Sem Daily.

Todos alteram o mesmo COPYBOOK.

Caos.

Com Daily.

Todos sabem quem está mexendo em quê.

---

User Story

No Agile quase tudo começa assim.

Como cliente

Quero agendar um PIX

Para realizar pagamentos futuros.

Isso parece simples.

Mas escondido existem dezenas de tarefas.

COBOL.

Db2.

MQ.

Logs.

SMF.

Segurança.

RACF.

Auditoria.

Rollback.

Monitoramento.

Performance.

---

Definition of Done

Esse conceito salva projetos.

Pronto significa:

Compila?

Sim.

Testado?

Sim.

Code Review?

Sim.

Documentado?

Sim.

Pipeline passou?

Sim.

Deploy aprovado?

Sim.

Agora sim.

---

Agile no Batch

Muitos acreditam:

"Batch não combina com Agile."

Grande engano.

Imagine um processamento noturno.

Antes:

8 horas

↓

ABEND S0C7

↓

Descobre de manhã.

Hoje:

Testes automatizados.

Validação.

Mock.

Datasets de teste.

Pipeline.

Muito menos risco.

---

Agile e CICS

Imagine uma transação bancária.

Sprint:

Criar nova tela BMS

↓

Modificar COBOL

↓

Atualizar MAPSET

↓

Testar CEDF

↓

Publicar

Tudo acontece dentro de um Sprint.

---

Agile e Db2

Outro exemplo.

Nova tabela

↓

DDL

↓

RUNSTATS

↓

BIND PACKAGE

↓

BIND PLAN

↓

Testes

↓

Deploy

Observe.

Não existe "programar".

Existe entregar uma funcionalidade.

---

Agile e DevOps

Hoje praticamente todo ambiente moderno IBM Z trabalha próximo disso:

Git

↓

Commit

↓

Pipeline

↓

Compile COBOL

↓

DBB

↓

Testes

↓

Code Review

↓

Deploy automático

↓

Validação

↓

Produção

Isso é Agile em estado puro.

---

O Grande Inimigo

O maior inimigo do Agile não é o waterfall.

É o multitasking.

Imagine.

Você começa:

Projeto A.

Parou.

Projeto B.

Parou.

Projeto C.

Parou.

Projeto D.

No fim...

Nada termina.

---

O Custo da Mudança

Existe um gráfico famoso.

Quanto mais tarde um erro aparece...

Mais caro fica.

No mainframe isso é ainda mais verdadeiro.

Imagine descobrir em produção:

MOVEs invertidos

↓

Saldo incorreto

↓

Milhões de contas afetadas

Quanto custou?

Muito.

---

Testes Automatizados

O Padawan moderno aprende rapidamente:

Testar manualmente não escala.

Hoje temos:

ZUnit.

Galasa.

IBM Z Virtual Test Platform.

Frameworks internos.

Tudo isso reduz riscos.

---

Integração Contínua

O velho fluxo:

sexta-feira

↓

deploy

↓

rezar

Foi substituído por:

Commit

↓

Pipeline

↓

Testes

↓

Deploy

Muito menos adrenalina.

---

Easter Egg nº 1

Você sabia?

O conceito de Sprint lembra muito os ciclos usados pela NASA durante o Projeto Apollo.

Os engenheiros entregavam pequenas evoluções sucessivas em vez de esperar a conclusão de todo o sistema.

Embora o Scrum moderno tenha outra origem, essa abordagem iterativa já aparecia em grandes projetos décadas antes.

---

Easter Egg nº 2

O próprio JES2 já trabalha em filas priorizadas.

Jobs possuem classes.

Prioridades.

Filas.

Dependências.

Curiosamente...

Muito parecido com um Backlog.

---

Easter Egg nº 3

O famoso ciclo

Editar

↓

Compile

↓

Execute

↓

Corrija

Existe desde os primeiros compiladores FORTRAN dos anos 1950.

Agile apenas expandiu essa filosofia para toda a organização.

---

Curiosidade

O maior Sprint do mundo provavelmente acontece diariamente.

Milhões de transações bancárias.

Bilhões de SQLs.

Milhares de Jobs.

Tudo funcionando continuamente.

O cliente nem percebe.

---

Dicas do Mestre Bellacosa

Nunca comece programando.

Leia a User Story.

Entenda o problema.

---

Converse com o usuário.

Cinco minutos de conversa economizam cinco dias de retrabalho.

---

Faça pequenas alterações.

Grandes mudanças geram grandes ABENDs.

---

Compile frequentemente.

Esperar três dias para compilar é receita para desastre.

---

Automatize tudo.

Quanto menos trabalho manual...

Menos erro humano.

---

Faça Code Review.

Quatro olhos encontram erros que dois ignoram.

---

Conheça o fluxo inteiro.

Não seja apenas "o programador COBOL".

Entenda:

JCL.

Db2.

MQ.

CICS.

IMS.

RACF.

SMF.

JES2.

Quanto maior sua visão...

Maior seu valor.

---

Perigos do Agile

Daily infinita

Se durar uma hora...

Não é Daily.

---

Sprint sem objetivo

"Vamos fazer algumas tarefas."

Isso não é Sprint.

---

Product Owner ausente

Sem prioridades...

Tudo vira prioridade.

---

Backlog gigante

Cinco mil histórias.

Ninguém consegue administrar isso.

---

Dívida técnica

"Depois corrigimos."

Depois nunca chega.

---

Falta de testes

Agile sem testes automatizados vira loteria.

---

Deploy manual

Copiar Load Module na mão em pleno século XXI aumenta o risco operacional.

---

Mudanças durante o Sprint

Se tudo muda todos os dias...

Nada termina.

---

Vantagens

✔ Feedback constante.

✔ Menor risco.

✔ Cliente participa.

✔ Correções rápidas.

✔ Maior qualidade.

✔ Melhor previsibilidade.

✔ Integração entre equipes.

✔ Evolução contínua.

✔ Entregas frequentes.

✔ Melhor moral da equipe.

---

Desvantagens

Também existem.

Nem tudo são flores.

Agile pode sofrer quando:

• a organização não dá autonomia ao time;

• o Product Owner não consegue priorizar;

• a equipe é constantemente interrompida por demandas urgentes;

• a documentação é negligenciada em nome da velocidade;

• há dependências fortes de sistemas legados sem planejamento adequado.

Além disso, ambientes regulados — comuns no setor financeiro — exigem controles formais de auditoria, segregação de funções e aprovação de mudanças. O desafio não é abandonar essas práticas, mas integrá-las ao fluxo ágil com automação, pipelines e governança.

---

O Caminho do Programador COBOL Padawan

No universo Bellacosa Mainframe, Agile não é um modismo nem uma desculpa para fazer reuniões. É uma maneira de reduzir riscos, aprender continuamente e entregar valor sem comprometer a estabilidade do IBM Z.

O Padawan que domina apenas COBOL escreve bons programas. O que compreende Agile, DevOps, testes automatizados, observabilidade, integração contínua, arquitetura e o ciclo de vida completo do software torna-se um profissional capaz de dialogar com desenvolvedores distribuídos, arquitetos, analistas de negócio, DBAs, administradores CICS e equipes de operações.

No fim da jornada, a maior lição é simples: o verdadeiro poder do Agile não está nos Sprints, nas Dailies ou nos quadros Kanban. Está na capacidade de transformar conhecimento em melhoria contínua. É exatamente isso que mantém o IBM Z relevante há mais de seis décadas: evoluir constantemente sem abrir mão da confiabilidade.

Como diria um velho Mestre Jedi do datacenter:

"O código pode ser legado. A forma de pensar nunca deve ser."

 

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.