Bellacosa Mainframe e a documentação de software

☕ Um Café no Bellacosa Mainframe

📚 MYNE E A BIBLIOTECA PERDIDA DO MAINFRAME — QUANDO O COBOL DESCOBRIU QUE CÓDIGO SEM DOCUMENTAÇÃO TAMBÉM PODE VIRAR UM LIVRO ESQUECIDO

Documentação, COBOL, auditoria, Configuration Management, Git, runbooks, dívida documental, conhecimento institucional, IA generativa — e o dia em que Myne descobriu que o maior risco do sistema não estava no programa, mas na cabeça do único programador que sabia como ele funcionava.

🎬 PRÓLOGO — MYNE ENCONTROU UM PROGRAMA COBOL

Myne abriu os olhos.

Não estava em Ehrenfest.

Não havia templo.

Não havia Ferdinand.

Não havia sequer uma biblioteca.

Diante dela existia uma tela preta com letras verdes.

READY

DSN SYSTEM(DB2P)

IKJ56700A ENTER USERID -

— Onde estão os livros?

Um velho programador apontou para milhares de datasets.

HLQ.PROD.COBOL
HLQ.PROD.COPYLIB
HLQ.PROD.JCL
HLQ.PROD.PROCLIB
HLQ.PROD.PARMLIB

Myne arregalou os olhos.

— Então... isso tudo é conhecimento?

— Mais ou menos.

— Onde está a documentação?

Silêncio.

O programador olhou para o teto.

Outro fingiu que estava analisando um dump.

Um terceiro tomou café.

Finalmente alguém respondeu:

— Pergunta para o Carlos.

Myne imediatamente percebeu que havia encontrado um problema muito mais grave do que a falta de livros.

A empresa possuía milhares de programas.

Mas parte importante do conhecimento necessário para compreendê-los estava armazenada em um dispositivo extremamente sofisticado, porém perigosamente volátil:

a memória dos funcionários.

Bem-vindo, jovem programador COBOL, à dungeon da documentação.

📜 CAPÍTULO 1 — CÓDIGO NÃO É DOCUMENTAÇÃO

Existe uma frase muito repetida no desenvolvimento:

“O código é a documentação.”

Ela contém alguma verdade, mas também pode esconder uma armadilha.

Veja:

       IF WS-TIPO-CLIENTE = 'E'
           PERFORM 8200-CALCULO-ESPECIAL
       END-IF.

Mesmo um iniciante consegue perceber o comportamento básico.

Se WS-TIPO-CLIENTE for igual a E, o programa executa 8200-CALCULO-ESPECIAL.

Ótimo.

Mas agora Myne começa a fazer perguntas.

— O que significa E?

— Especial.

— O que é um cliente especial?

— Não sei.

— Quem decidiu isso?

— Não sei.

— Por que ele recebe cálculo diferente?

— Também não sei.

— Desde quando?

— Talvez 2004.

— Posso remover?

— NÃO!

E encontramos a diferença entre código e conhecimento.

O código descreve muito bem aquilo que o computador precisa executar.

Mas nem sempre preserva:

por que determinada decisão foi tomada;
qual requisito originou a regra;
quem solicitou a alteração;
quais impactos foram considerados;
quais sistemas dependem dela;
quais procedimentos operacionais existem;
como recuperar o sistema quando algo dá errado.

Imagine encontrar:

      * ALTERADO JOAO 14/06/2004

Excelente.

Descobrimos que João esteve ali.

Infelizmente, João não deixou pistas sobre aquilo que estava pensando.

Myne suspira.

Um livro que diz apenas:

“Capítulo alterado por João.”

não preserva conhecimento suficiente para reconstruir sua história.

🧠 CAPÍTULO 2 — A EMPRESA POSSUI UMA MEMÓRIA

Uma organização também possui memória.

Só que ela não fica em um único lugar.

Pode estar espalhada por:

Código-fonte
     │
     ├── COBOL
     ├── JCL
     ├── COPYBOOKS
     ├── procedimentos
     ├── tickets
     ├── diagramas
     ├── e-mails
     ├── Wikis
     ├── runbooks
     ├── atas
     ├── manuais
     └── pessoas

O último elemento merece atenção especial.

Imagine:

CONHECIMENTO DO SISTEMA XPTO

20% documentação
30% código
50% Carlos

Temos um problema.

Carlos pode:

sair da empresa;
mudar de departamento;
entrar de férias;
esquecer detalhes;
aposentar-se;
simplesmente não estar disponível durante um incidente.

Isso transforma Carlos em algo parecido com um Single Point of Failure humano.

Existe inclusive uma expressão informal usada em engenharia de software: bus factor.

Ela procura representar quantas pessoas poderiam ficar indisponíveis antes que um projeto perdesse conhecimento crítico.

Se a resposta for:

uma,

temos enorme concentração de conhecimento.

Myne ficaria horrorizada.

Para alguém que passou a vida tentando preservar livros, colocar conhecimento crítico exclusivamente na memória humana seria equivalente a possuir apenas um exemplar de um livro importantíssimo e guardá-lo ao lado de uma lareira.

⚔️ CAPÍTULO 3 — POR QUE PROGRAMADORES NÃO GOSTAM DE DOCUMENTAR?

Durante décadas, gestores perguntaram:

Como fazer os programadores documentarem?

É uma pergunta compreensível.

Mas pode ser a pergunta errada.

É fácil responder:

— Programador não gosta de escrever.

Alguns realmente não gostam.

Outros têm dificuldade para transformar raciocínio técnico em texto compreensível.

Mas existe um problema organizacional muito mais interessante.

Imagine dois programadores.

Programador A

Codificação ............ 8 horas
Testes ................. 3 horas
Documentação ........... 2 horas
-------------------------------
Total .................. 13 horas

Programador B

Codificação ............ 8 horas
Testes ................. 2 horas
Documentação ........... 0 horas
-------------------------------
Total .................. 10 horas

Se a empresa medir produtividade apenas pela velocidade da entrega, quem parece melhor?

Portanto, não documentar pode ser perfeitamente racional dentro de um sistema de incentivos mal construído.

A empresa publica:

“Documentação é fundamental.”

Mas o projeto comunica:

PRAZO > DOCUMENTAÇÃO

E o funcionário aprende rapidamente qual regra realmente vale.

Myne percebe algo importante:

cultura organizacional não é aquilo que está escrito no manual. É aquilo que a organização recompensa, tolera e pune.

🏰 CAPÍTULO 4 — DOCUMENTAÇÃO NÃO DEVERIA SER UMA TAREFA POSTERIOR

Um projeto tradicional frequentemente funciona assim:

REQUISITO
    ↓
ANÁLISE
    ↓
DESENVOLVIMENTO
    ↓
TESTE
    ↓
PRODUÇÃO
    ↓
"Esquecemos da documentação."

Nesse modelo, documentação virou a última obrigação antes da libertação do programador.

Resultado?

Ele está cansado.

O prazo terminou.

Outro projeto já começou.

O gerente quer implantação.

E alguém pergunta:

— Você pode escrever o manual?

Nasce então o clássico:

MANUAL_SISTEMA_FINAL.DOC

Seguido, meses depois, por:

MANUAL_SISTEMA_FINAL2.DOC
MANUAL_SISTEMA_NOVO.DOC
MANUAL_SISTEMA_NOVO_FINAL.DOC
MANUAL_SISTEMA_NOVO_FINAL_OK.DOC

Isso não é versionamento.

É arqueologia digital.

A solução conceitual é colocar documentação dentro do ciclo de desenvolvimento:

REQUISITO
    ↓
DESIGN
    ↓
CÓDIGO
    +
DOCUMENTAÇÃO
    ↓
TESTE
    +
TESTE DA DOCUMENTAÇÃO
    ↓
REVIEW
    ↓
DEPLOY

Agora surge uma regra poderosa:

mudança no sistema pode significar mudança na documentação.

Não necessariamente toda alteração muda todo documento.

Mas toda alteração deveria provocar a pergunta:

Quais informações precisam ser atualizadas por causa desta mudança?

🔗 CAPÍTULO 5 — UMA ALTERAÇÃO COBOL NUNCA ESTÁ SOZINHA

O iniciante frequentemente imagina:

PROGRAMA COBOL

Mas sistemas corporativos são ecossistemas.

Uma alteração pode atingir:

REQUISITO
   │
   ├── COBOL
   ├── COPYBOOK
   ├── JCL
   ├── PROC
   ├── VSAM
   ├── Db2
   ├── CICS
   ├── MQ
   ├── API
   ├── batch
   ├── procedimento operacional
   ├── troubleshooting
   └── manual do usuário

Imagine aumentar um campo:

05 CLIENTE-ID PIC 9(06).

para:

05 CLIENTE-ID PIC 9(08).

Parece simples.

Mas Myne pergunta:

— O copybook compartilhado mudou?

— Sim.

— Arquivos VSAM?

— Talvez.

— Layout de interface?

— Sim.

— Programa consumidor?

— Também.

— Documentação?

Silêncio novamente.

Essa é a essência da análise de impacto.

Documentação não está fora do sistema.

Ela faz parte do conjunto de artefatos que descrevem o sistema.

🧙 CAPÍTULO 6 — MYNE DESCOBRE CONFIGURATION MANAGEMENT

Chegamos a um conceito importante para quem está começando no mainframe:

Configuration Management.

Simplificando bastante, Configuration Management procura responder perguntas como:

O que existe?
Qual versão existe?
Qual versão está em produção?
Quem alterou?
Quando alterou?
Por que alterou?
O que depende disso?
Qual era a configuração anterior?

Você provavelmente já percebeu que isso não interessa somente ao código.

Imagine:

RUNBOOK-PAGAMENTOS

Versão: 4.7
Sistema: PAY001
Owner: Payments Operations
Aprovador: Production Control
Última revisão: 23/09/2026
Próxima revisão: 23/03/2027
Change: CHG-98472
Status: APPROVED

Agora temos algo auditável.

Podemos perguntar:

Qual procedimento estava válido em 14 de março?

E recuperar aquela versão.

Essa capacidade é essencial.

💀 CAPÍTULO 7 — ÀS 03:17, A DOCUMENTAÇÃO VIRA PRODUÇÃO

03:17.

Sim, jovem padawan.

Você encontrou o easter egg.

O telefone toca.

INCIDENTE CRÍTICO
SISTEMA DE PAGAMENTOS

O operador consulta o procedimento.

1. Localizar JOB PAYR001.
2. Cancelar execução.
3. Executar PAYREC01.
4. Verificar mensagem PAY003I.

Ele está prestes a executar o passo 3 quando alguém grita:

— NÃO EXECUTA!

— Por quê?

— PAYREC01 foi aposentado.

— Quando?

— Ano passado.

— O procedimento manda executar.

Silêncio.

A documentação está oficialmente publicada.

Mas descreve um sistema que já não existe.

Temos então duas verdades:

VERDADE EXECUTÁVEL
        ≠
VERDADE DOCUMENTADA

Esse fenômeno poderia ser chamado de documentation drift ou deriva documental.

E aqui aparece uma conclusão contraintuitiva:

documentação errada pode ser pior que documentação inexistente.

Se não houver documentação, o operador sabe que precisa investigar.

Quando existe um procedimento aparentemente oficial, ele pode confiar nele.

🧪 CAPÍTULO 8 — DOCUMENTAÇÃO TAMBÉM PRECISA SER TESTADA

Essa ideia é extraordinariamente importante.

Considere:

1. Entre no SDSF.
2. Localize o job.
3. Execute comando X.
4. Confirme mensagem Y.
5. Reinicie componente Z.

Um especialista lê e afirma:

— Perfeito.

Mas entregue isso a alguém que nunca executou o procedimento.

Ele pergunta:

— Em qual painel?

— Como localizo o job?

— Qual comando?

— Onde aparece Y?

— E se Y não aparecer?

Descobrimos cinco buracos em trinta segundos.

Portanto, documentação operacional pode possuir algo parecido com teste funcional.

Uma pessoa representativa do público-alvo tenta realizar a tarefa utilizando somente as instruções.

Isso revela:

passos ausentes;
pressupostos ocultos;
terminologia inadequada;
ambiguidades;
comandos errados;
dependências não documentadas.

Myne aprovaria.

Não basta imprimir o livro.

Precisamos verificar se o leitor consegue utilizá-lo.

📚 CAPÍTULO 9 — MAIS DOCUMENTAÇÃO NÃO SIGNIFICA MELHOR DOCUMENTAÇÃO

Existe outra pergunta antiga:

Quanto devemos documentar?

Resposta errada:

Tudo.

Outra resposta errada:

O mínimo possível.

O objetivo é:

DOCUMENTAÇÃO NECESSÁRIA
        +
CORRETA
        +
ATUAL
        +
ENCONTRÁVEL
        +
COMPREENSÍVEL
        +
ADEQUADA À TAREFA

Um manual de 900 páginas pode ser praticamente inútil durante um incidente.

O operador talvez precise de duas páginas.

Diferentes necessidades exigem diferentes documentos:

Necessidade	Informação
compreender arquitetura	Architecture Overview
desenvolver	Developer Guide
operar	Runbook
investigar falha	Troubleshooting Guide
integrar	Interface/API Specification
recuperar desastre	Disaster Recovery Procedure
utilizar aplicação	User Guide
modificar	Design/Change Documentation
aprender sistema	Onboarding Guide
auditar	evidências e histórico

A antiga ideia de colocar tudo no gigantesco Manual do Sistema frequentemente cria documentos impossíveis de consumir.

🗺️ CAPÍTULO 10 — DOCUMENTAÇÃO PRECISA SER ENCONTRÁVEL

Myne finalmente recebe uma boa notícia.

— Temos documentação!

— Onde?

— Share.

— Qual?

— Não lembro.

— Nome?

— Alguma coisa como PAY...

Depois de vinte minutos:

\\server\departamento\projetos\old\sistemas\pagamentos\
documentacao\backup\antigo\

Myne quase desmaia.

Informação que existe mas não pode ser encontrada possui valor operacional próximo de zero.

Portanto, governança documental envolve também:

taxonomia;
pesquisa;
nomes consistentes;
metadados;
owners;
classificação;
links;
relacionamentos;
controle de versão.

Bibliotecas descobriram isso séculos atrás.

Não basta possuir livros.

Precisamos saber onde eles estão e como encontrá-los.

🏛️ CAPÍTULO 11 — CENTRALIZAR OU DESCENTRALIZAR?

O problema já existia décadas atrás.

Deveríamos possuir um departamento central de documentação?

Ou documentadores dentro das equipes?

Centralizado

          DOCUMENTAÇÃO
               │
     ┌─────────┼─────────┐
     ↓         ↓         ↓
 SISTEMA A  SISTEMA B  SISTEMA C

Excelente para:

padrões;
qualidade;
independência;
governança;
consistência.

Mas pode ficar distante da tecnologia.

Descentralizado

TIME A → documentação A
TIME B → documentação B
TIME C → documentação C

Excelente proximidade.

Mas pode produzir três dialetos diferentes.

Uma solução interessante é o modelo federado:

          GOVERNANÇA CENTRAL
                 │
       padrões e ferramentas
                 │
       ┌─────────┼─────────┐
       ↓         ↓         ↓
     TIME A    TIME B    TIME C
       │         │         │
     OWNER     OWNER     OWNER

O centro define regras.

As equipes preservam conhecimento local.

👑 CAPÍTULO 12 — TODO DOCUMENTO PRECISA DE UM DONO

Uma regra simples evita enorme quantidade de caos:

todo documento relevante deve possuir owner.

Owner não significa necessariamente autor.

O owner responde pela validade.

Pense assim:

DOCUMENTO
   ↓
OWNER
   ↓
REVISÃO
   ↓
APROVAÇÃO
   ↓
PUBLICAÇÃO
   ↓
USO
   ↓
NOVA REVISÃO
   ↓
ARQUIVAMENTO

Documento sem proprietário tende a virar órfão.

E órfãos digitais envelhecem silenciosamente.

🧹 CAPÍTULO 13 — DOCUMENTO OBSOLETO PRECISA MORRER

Esse ponto é pouco discutido.

Criar documentação é importante.

Mas aposentar documentação também é.

Imagine encontrar:

RUNBOOK-PAY-2019
RUNBOOK-PAY-2021
RUNBOOK-PAY-NOVO
RUNBOOK-PAY-FINAL
RUNBOOK-PAY-ATUAL

Qual é válido?

Se ninguém souber, temos risco operacional.

Um processo maduro deveria permitir estados como:

DRAFT
REVIEW
APPROVED
PUBLISHED
SUPERSEDED
ARCHIVED

Assim sabemos que determinado documento existe historicamente, mas não deve mais orientar operações atuais.

Myne chamaria isso de diferença entre:

arquivo histórico e livro de uso corrente.

💳 CAPÍTULO 14 — DÍVIDA DOCUMENTAL

Programadores conhecem Technical Debt.

Mas existe outra dívida:

Documentation Debt.

Toda mudança não refletida na documentação cria um pequeno débito.

No começo ninguém percebe.

Mudança 1 → documento quase correto
Mudança 2 → pequeno erro
Mudança 3 → faltam dois procedimentos
Mudança 4 → diagrama incorreto
Mudança 5 → ninguém confia mais

Finalmente acontece algo curioso:

“Não consulte a Wiki porque está desatualizada.”

Pronto.

A organização perdeu confiança em seu próprio repositório de conhecimento.

Podemos imaginar:

Documentation Debt ↑

MTTR ↑
Onboarding ↑
Dependência de especialistas ↑
Retrabalho ↑
Risco operacional ↑
Risco de auditoria ↑

O custo economizado ontem reaparece com juros.

🔍 CAPÍTULO 15 — ENTRA O AUDITOR

Agora o auditor chega.

Um auditor fraco pergunta:

— Vocês possuem documentação?

A equipe mostra cinquenta PDFs.

Check.

Auditor satisfeito.

Myne não.

Um auditor melhor pergunta:

“Mostre uma alteração recente em produção.”

Escolhemos:

CHG-98472

Agora reconstruímos:

REQUISITO
    ↓
ANÁLISE
    ↓
CHANGE
    ↓
ALTERAÇÃO COBOL
    ↓
TESTE
    ↓
APROVAÇÃO
    ↓
DEPLOY
    ↓
DOCUMENTAÇÃO
    ↓
COMUNICAÇÃO

Depois fazemos o contrário.

Escolhemos um programa em produção:

PAYB0031

E perguntamos:

Qual versão?
Qual change colocou isso aqui?
Quem aprovou?
Quais testes existem?
Qual requisito originou?
Qual documentação foi atualizada?

Isso é rastreabilidade.

Não estamos procurando papel.

Estamos procurando evidência de controle.

⚔️ CAPÍTULO 16 — O AUDITOR PROCURA A EMPRESA REAL

Existe uma diferença fundamental entre:

PROCESSO DOCUMENTADO

PROCESSO REAL

O manual diz:

Em incidentes críticos consultar RUNBOOK-PAY.

O auditor entrevista operadores.

— O que você faz quando PAY cai?

— Chamo o Zé.

— E o runbook?

— Ah... aquilo está velho.

Bingo.

Encontramos uma diferença entre governança formal e comportamento operacional.

A empresa pensa que possui:

INCIDENTE
   ↓
RUNBOOK
   ↓
RESOLUÇÃO

Na realidade possui:

INCIDENTE
   ↓
WhatsApp
   ↓
"CHAMA O ZÉ"

Zé virou middleware humano.

E não possui redundância.

🤖 CAPÍTULO 17 — MYNE CONHECE A INTELIGÊNCIA ARTIFICIAL

Então chega 2026.

Myne encontra uma máquina extraordinária.

Ela recebe:

COBOL;
JCL;
copybooks;
diagramas;
tickets;
commits;
logs.

E produz explicações.

— Ela escreve livros?!

Quase.

IA generativa pode ajudar enormemente na documentação.

Por exemplo, pode transformar:

       EVALUATE WS-STATUS
          WHEN 'A'
             PERFORM 1000-ATIVO
          WHEN 'B'
             PERFORM 2000-BLOQUEADO
          WHEN OTHER
             PERFORM 9000-ERRO
       END-EVALUATE.

em uma explicação preliminar.

Pode ainda:

resumir código;
explicar campos;
gerar diagramas preliminares;
converter tickets em release notes;
comparar versões;
identificar documentação possivelmente afetada;
criar perguntas para revisão;
produzir rascunhos de runbooks.

Fantástico.

Mas existe uma armadilha gigantesca.

☠️ CAPÍTULO 18 — IA PODE DOCUMENTAR PERFEITAMENTE UMA COISA ERRADA

Imagine a IA afirmar:

“O campo E representa cliente empresarial.”

Texto bonito.

Gramática impecável.

Completamente errado.

Na verdade:

E = CLIENTE ESPECIAL

Esse é um novo tipo de risco.

Antigamente tínhamos documentação ruim obviamente ruim.

Agora podemos possuir documentação errada extremamente convincente.

Portanto:

IA
 ↓
RASCUNHO
 ↓
SME TÉCNICO
 ↓
USUÁRIO
 ↓
VALIDAÇÃO
 ↓
APROVAÇÃO
 ↓
PUBLICAÇÃO

Nunca:

IA
 ↓
PRODUÇÃO

A inteligência artificial reduz o custo de produção.

Ela não transfere responsabilidade pela verdade.

🧰 CAPÍTULO 19 — DOCUMENTATION AS CODE

Agora Myne encontra Git.

E quase pede Ferdinand em casamento novamente.

Porque finalmente os livros possuem histórico automático.

Podemos organizar:

docs/
├── architecture/
├── development/
├── operations/
├── troubleshooting/
├── interfaces/
└── security/

Uma alteração começa:

git checkout -b CHG-98472

O programador altera:

src/PAYB0031.cbl

e também:

docs/operations/payment-runbook.md

Então:

CODE
  +
DOC
  ↓
PULL REQUEST
  ↓
REVIEW
  ↓
PIPELINE
  ↓
RELEASE

Isso é poderoso porque aproxima documentação do mesmo fluxo utilizado pelo software.

Temos:

versionamento;
histórico;
autoria;
comparação;
revisão;
aprovação;
automação.

Código e conhecimento começam a viajar juntos.

🧪 CAPÍTULO 20 — UM PASSO A PASSO PARA O PROGRAMADOR COBOL

Você recebeu uma alteração.

Não pense apenas:

“Qual linha COBOL vou mudar?”

Faça algo parecido com isto.

Passo 1 — descubra o motivo

Pergunte:

Qual problema estamos resolvendo?

Passo 2 — descubra o impacto

Liste:

COBOL?
COPYBOOK?
JCL?
Db2?
VSAM?
CICS?
MQ?
API?
batch?
usuário?
operação?

Passo 3 — localize documentação relacionada

Procure:

Architecture
Developer Guide
Runbook
Interface Specification
User Guide
Troubleshooting

Passo 4 — altere código e conhecimento juntos

Não espere três meses.

Passo 5 — teste ambos

O programa funciona?

A instrução também?

Passo 6 — peça revisão

Técnico revisa tecnologia.

Usuário revisa significado.

Operação revisa execução.

Passo 7 — preserve rastreabilidade

Relacione:

REQUISITO → CHANGE → CÓDIGO → TESTE → DOCUMENTAÇÃO

Passo 8 — retire informação obsoleta

Não deixe armadilhas históricas disponíveis como instrução atual.

🧙‍♀️ CAPÍTULO 21 — MYNE CRIA AS DEZ REGRAS DA BIBLIOTECA DO MAINFRAME

Depois de observar aquela organização, Myne escreve:

I. Código não substitui contexto.

II. Toda mudança deve avaliar impacto documental.

III. Todo documento crítico precisa de owner.

IV. Documentação precisa possuir versão.

V. Informação precisa ser encontrável.

VI. Procedimentos críticos precisam ser testados.

VII. Documento obsoleto precisa ser claramente aposentado.

VIII. IA pode escrever rascunhos; humanos continuam responsáveis pela verdade.

IX. Conhecimento crítico não pode existir somente na cabeça de uma pessoa.

X. Documentação faz parte do produto.

Ferdinand lê.

Fica em silêncio.

— Onze regras seriam mais completas.

Myne fecha o livro.

— Dez ficam melhores num slide.

☕ EPÍLOGO — O ÚLTIMO LIVRO DE CARLOS

Alguns meses depois, Carlos anunciou aposentadoria.

Ninguém entrou em pânico.

Durante meses, a equipe havia transformado seu conhecimento em:

Architecture Guides
Runbooks
Troubleshooting Guides
Decision Records
Diagramas
README
Procedimentos
Histórico de mudanças

Mais importante: outras pessoas haviam utilizado e testado aquele conhecimento.

No último dia, Carlos deixou sobre a mesa uma pequena folha.

Myne encontrou.

Nela estava escrito:

03:17

Se PAYB0031 apresentar S0C7 depois do fechamento,
não reinicie imediatamente.

Verifique primeiro o arquivo PAY.IN.TRANS.

E não acredite no procedimento de 2019.

Myne sorriu.

Digitalizou a informação.

Criou um ticket.

Atualizou o troubleshooting.

Relacionou ao sistema.

Mandou revisar.

E destruiu a folha.

Porque finalmente aquela empresa havia compreendido algo que bibliotecários sabem há séculos:

conhecimento que não pode ser encontrado não está verdadeiramente disponível.

Conhecimento que não pode ser verificado não é confiável.

Conhecimento que depende de uma única pessoa não pertence realmente à organização.

E conhecimento que não acompanha a evolução do sistema lentamente se transforma em ficção.

Para um programador COBOL iniciante, talvez essa seja uma das lições mais importantes da carreira.

Você não herdará apenas programas.

Herdará decisões tomadas por pessoas que talvez nunca conheça.

Encontrará campos criados antes de você nascer.

COPYBOOKs compartilhados por dezenas de aplicações.

JCLs cujo comentário mais recente terá quinze anos.

Regras de negócio que sobreviveram a três presidentes da empresa, quatro arquiteturas e seis gerações de programadores.

Um dia alguém também encontrará o seu código.

E encontrará algo como:

      *---------------------------------------------------------*
      * CHG-98472 - 23/09/2026                                 *
      * ALTERADA REGRA DE CLIENTE ESPECIAL.                    *
      * MOTIVO: NOVA REGRA CONTRATUAL.                          *
      * DOCUMENTACAO: DOC/PAYMENTS/RULES-CLIENTE-ESPECIAL.MD    *
      *---------------------------------------------------------*

Essa pessoa talvez nunca saiba seu nome.

Mas saberá por que aquilo existe.

E existe algo profundamente bonito nisso.

Porque mainframes são máquinas construídas para sobreviver ao tempo.

COBOL também.

Mas sistemas de cinquenta anos não sobrevivem apenas porque o hardware continua funcionando.

Eles sobrevivem porque sucessivas gerações de profissionais conseguem receber, compreender, modificar e transmitir conhecimento.

Somos temporários.

O sistema pode continuar.

O código fica.

As decisões ficam.

A documentação deveria ficar também.

E talvez Myne, olhando para milhões de linhas COBOL preservadas durante décadas, finalmente percebesse que havia encontrado uma biblioteca muito diferente daquela que sempre sonhou construir.

Uma biblioteca na qual alguns livros são executáveis.

E onde esquecer de atualizar uma página pode, às 03:17 da manhã, derrubar produção.

Bem-vindo à Biblioteca do Mainframe.

Seu próximo commit também é uma página da história.

Translate

sexta-feira, 1 de junho de 2001