Bellacosa Mainframe divida tecnica decisões erradas que pagamos até hoje

☕💣📋 DÍVIDA TÉCNICA NO MAINFRAME — O EMPRÉSTIMO QUE VOCÊ FEZ EM 1998 E AINDA ESTÁ PAGANDO COM JUROS EM 2026

Existe uma lenda antiga nos CPDs.

Ela diz que, em algum lugar do ambiente de produção, existe um programa COBOL que ninguém entende.

Ninguém sabe quem escreveu.

Ninguém sabe por que funciona.

Ninguém sabe o que acontece se ele parar.

Mas todos sabem de uma coisa:

ninguém tem coragem de mexer nele.

Se você trabalha em Mainframe há algum tempo, provavelmente já encontrou um desses.

Talvez ele tenha 30 mil linhas.

Talvez possua 700 GO TO.

Talvez utilize arquivos VSAM que nem aparecem mais na documentação.

Talvez tenha comentários escritos por alguém que já se aposentou há vinte anos.

E talvez ele continue processando milhões de reais por dia.

Parabéns.

Você acabou de encontrar um dos sintomas mais clássicos da dívida técnica.

O QUE É DÍVIDA TÉCNICA?

O termo foi criado por Ward Cunningham.

A ideia é simples.

Você faz uma escolha rápida hoje para ganhar velocidade.

Em troca, aceita que precisará corrigir aquilo futuramente.

É exatamente igual a um empréstimo bancário.

Você recebe um benefício imediato.

Mas depois paga juros.

No software, os juros aparecem na forma de:

retrabalho;
manutenção mais lenta;
defeitos;
incidentes;
dificuldade de evolução;
dependência de especialistas.

O problema é que muitas empresas pegam esse empréstimo todos os dias.

E quase nunca pagam.

O DIA EM QUE O SISTEMA COMEÇA A COBRAR JUROS

Imagine um programador COBOL júnior.

Recebe uma demanda urgente.

Precisa incluir um novo código de operação.

O correto seria:

revisar regras;
criar módulo reutilizável;
atualizar documentação;
executar testes.

Mas o prazo está apertado.

Então ele faz:

IF COD-OPER = '99'
   MOVE 'S' TO FLAG-ESPECIAL
END-IF.

Entrega.

Funciona.

Todos ficam felizes.

Seis meses depois surge:

Operação 98.

Depois 97.

Depois 96.

Quando alguém percebe, existe:

IF COD-OPER = '99'
OR COD-OPER = '98'
OR COD-OPER = '97'
OR COD-OPER = '96'

O programa continua funcionando.

Mas ficou pior.

Essa diferença entre funcionar e ser saudável é onde mora a dívida técnica.

COMO IDENTIFICAR DÍVIDA TÉCNICA

Os sinais são sempre parecidos.

1. Programas gigantes

Quando um COBOL possui:

10 mil linhas;
20 mil linhas;
50 mil linhas;

ninguém consegue compreender tudo.

Complexidade gera risco.

2. Dependência de uma única pessoa

Quando você ouve:

"Somente o João conhece esse sistema."

Acenda o alerta vermelho.

O João pode tirar férias.

O João pode mudar de empresa.

O João pode se aposentar.

O sistema precisa sobreviver sem heróis.

3. Medo de alterar

Se toda mudança gera receio:

"Vamos torcer para não derrubar produção."

Existe dívida técnica.

4. Muitas correções

Quando a equipe passa mais tempo corrigindo do que evoluindo.

O sistema está pagando juros elevados.

AS PRINCIPAIS MÉTRICAS

Métricas transformam sensação em informação.

Sem métricas ninguém sabe se está melhorando.

1. LEAD TIME

Tempo entre solicitação e entrega.

Exemplo:

Pedido feito em:

01/06

Produção:

10/06

Lead Time = 9 dias

Quanto menor melhor.

2. CYCLE TIME

Tempo efetivamente gasto desenvolvendo.

Exemplo:

Demanda recebida.

Ficou parada cinco dias.

Desenvolvimento levou dois dias.

Cycle Time = 2 dias.

3. CHANGE FAILURE RATE

Percentual de mudanças que causam problemas.

Exemplo:

100 implantações.

10 causaram incidentes.

Taxa:

10%

Quanto menor melhor.

4. MTTR

Mean Time To Recovery.

Tempo médio para recuperar produção.

Exemplo:

ABEND às 10h.

Sistema normal às 11h.

MTTR = 1 hora.

5. REWORK

Retrabalho.

Mede quanto esforço foi gasto corrigindo erros.

Imagine:

100 horas trabalhadas.

25 horas corrigindo problemas.

Rework:

25%

Muito alto.

6. REFATORAÇÃO

Esforço dedicado a melhorar código existente.

Uma equipe saudável normalmente reserva tempo para:

limpeza;
reorganização;
modularização.

ENTENDENDO O GRÁFICO DA LINEARB

Imagine:

59% Novo Trabalho

17% Refatoração

24% Retrabalho

Significa:

A cada 100 horas:

59 horas criam valor.

17 horas melhoram qualidade.

24 horas apagam incêndios.

Quase um quarto da energia da equipe foi desperdiçada.

COMO REDUZIR DÍVIDA TÉCNICA

Agora chegamos ao ponto mais importante.

PASSO 1 — MAPEAR O PROBLEMA

Não tente resolver tudo.

Primeiro descubra:

quais programas mudam mais;
quais causam mais incidentes;
quais possuem maior complexidade.

Faça uma planilha simples.

Programa	Alterações	Incidentes
FIN001	120	15
FIN002	10	0
FIN003	95	12

Comece pelos maiores problemas.

PASSO 2 — CRIAR BACKLOG TÉCNICO

Muitas empresas possuem backlog funcional.

Poucas possuem backlog técnico.

Crie itens como:

remover código morto;
modularizar rotina;
eliminar duplicação;
documentar interfaces.

Essas atividades precisam ser visíveis.

PASSO 3 — REFATORAR PEQUENO

Erro clássico:

"Vamos reescrever tudo."

Não faça isso.

Melhore gradualmente.

Hoje:

extrair um parágrafo.

Amanhã:

eliminar duplicação.

Depois:

criar módulo reutilizável.

Pequenas vitórias acumulam grandes resultados.

PASSO 4 — DOCUMENTAR

Documentação não precisa ser um livro.

Basta responder:

o que faz;
entradas;
saídas;
dependências.

Já ajuda enormemente.

PASSO 5 — REVISÃO DE CÓDIGO

Mesmo no Mainframe.

Principalmente no Mainframe.

Checklist simples:

✓ Nome adequado

✓ Lógica clara

✓ Tratamento de erro

✓ Performance

✓ Documentação

✓ Testes

PASSO 6 — TESTES

O segredo dos sistemas modernos.

Sem testes:

refatorar é perigoso.

Com testes:

refatorar é seguro.

Mesmo em COBOL.

Ferramentas como:

IBM Debug Tool
IBM Application Discovery
IBM ZUnit
Micro Focus Unit Testing

ajudam muito.

PASSO 7 — REDUZIR COMPLEXIDADE

Pergunta mágica:

"Existe uma forma mais simples?"

Sempre existe.

Quanto mais simples:

menor risco;
menor manutenção;
menor custo.

FERRAMENTAS ÚTEIS

IBM Application Discovery

Mapeia dependências.

Mostra:

programas;
copybooks;
arquivos;
fluxos.

Excelente para arqueologia de sistemas.

SonarQube

Analisa qualidade.

Detecta:

duplicação;
complexidade;
vulnerabilidades.

Git

Mesmo para Mainframe.

Ajuda a controlar mudanças.

Jira

Controle de backlog técnico.

ServiceNow

Correlação entre incidentes e sistemas.

O SEGREDO QUE NINGUÉM CONTA

A maioria das dívidas técnicas não nasce do código.

Nasce da organização.

Promessas irreais.

Prazos impossíveis.

Mudanças constantes.

Prioridades conflitantes.

O código apenas reflete o ambiente em que foi criado.

EASTER EGG MAINFRAME

Existe um teste simples.

Abra um programa COBOL.

Role até o final.

Se encontrar:

GO TO FIM-PROGRAMA

não se assuste.

Se encontrar:

GO TO INICIO

fique atento.

Se encontrar:

GO TO PARAGRAFO-XYZ

que chama outro GO TO que chama outro GO TO...

Parabéns.

Você encontrou uma relíquia arqueológica do período Jurássico dos sistemas corporativos.

O CAMINHO DE EVOLUÇÃO DO PROGRAMADOR JÚNIOR

Nível 1:

Faz funcionar.

Nível 2:

Faz funcionar corretamente.

Nível 3:

Faz funcionar de forma simples.

Nível 4:

Faz funcionar de forma sustentável.

Nível 5:

Melhora o sistema toda vez que toca nele.

É nesse último estágio que nasce o verdadeiro arquiteto de sistemas.

A GRANDE LIÇÃO

O programador iniciante acredita que seu trabalho é escrever código.

O programador experiente descobre que seu trabalho é reduzir complexidade.

Código novo gera valor.

Mas código limpo preserva valor.

A dívida técnica não explode como um ABEND.

Ela cresce silenciosamente.

Linha após linha.

Workaround após workaround.

Correção após correção.

Até o dia em que uma mudança de cinco minutos passa a exigir três semanas.

Nesse momento os juros finalmente chegaram.

E como qualquer empréstimo antigo, quanto mais tempo você esperar para pagar, mais caro ficará.

El Jefe Midnight Lunch

Translate

terça-feira, 2 de junho de 2026