Translate

Mostrar mensagens com a etiqueta modernizacao de sistemas. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta modernizacao de sistemas. Mostrar todas as mensagens

sexta-feira, 12 de junho de 2026

☕🚀 COBOL FORA DO MAINFRAME: POR QUE ELE NÃO CONQUISTOU O MUNDO COMO JAVA, C# E PYTHON?


Bellacosa Mainframe e tenta entender a razao do Cobol nao existir fora do Mainframe

☕🚀 COBOL FORA DO MAINFRAME: POR QUE ELE NÃO CONQUISTOU O MUNDO COMO JAVA, C# E PYTHON?

Quando alguém fala em COBOL, a maioria das pessoas imediatamente imagina um enorme IBM Z, salas refrigeradas, bancos, seguradoras e sistemas que movimentam bilhões de dólares por dia.

Mas existe uma curiosidade que poucos conhecem:

O COBOL nunca foi exclusivo do Mainframe.

Durante décadas existiram versões para:

  • MS-DOS

  • Windows

  • Linux

  • Unix

  • AIX

  • HP-UX

  • Solaris

  • AS/400

  • VMS

  • até mesmo Raspberry Pi atualmente

Empresas como Micro Focus, Fujitsu, RM/COBOL, Acucobol, GNUCobol e outras investiram milhões tentando popularizar o COBOL fora do universo IBM.

Mesmo assim, quando ouvimos a palavra COBOL em 2026, quase todo mundo associa imediatamente ao Mainframe.

A pergunta é inevitável:

Por que isso aconteceu?

Por que Java virou universal?

Por que C conquistou sistemas operacionais?

Por que Python dominou a automação?

E por que COBOL permaneceu praticamente "preso" ao Mainframe?

A resposta envolve tecnologia, mercado, marketing, história, cultura corporativa e até psicologia.

Pegue seu café.

Hoje vamos mergulhar em uma das maiores curiosidades da história da computação.


O MAIOR MITO SOBRE COBOL

Existe uma crença popular:

"COBOL só funciona em Mainframe."

Isso nunca foi verdade.

Desde os anos 70 já existiam compiladores COBOL para minicomputadores.

Nos anos 80 surgiram versões para:

  • DOS

  • Unix

  • VAX/VMS

Nos anos 90:

  • Windows

  • OS/2

  • Linux

Nos anos 2000:

  • .NET

  • JVM

  • Web Services

Tecnicamente falando, o COBOL poderia ter seguido praticamente qualquer caminho.

Mas não seguiu.


O PROBLEMA NUNCA FOI A LINGUAGEM

Essa é a primeira coisa que surpreende muita gente.

O COBOL não fracassou fora do Mainframe porque era ruim.

Na verdade ele possuía diversas vantagens.

Extremamente legível

Exemplo:

IF SALDO-CONTA IS GREATER THAN LIMITE-CREDITO
   DISPLAY "LIMITE EXCEDIDO"
END-IF

Até alguém sem conhecimento profundo consegue entender.


Excelente para regras de negócio

Bancos adoram COBOL porque ele descreve regras empresariais com clareza.

Por exemplo:

COMPUTE JUROS =
    VALOR * TAXA / 100

Não existe mistério.


Forte manipulação de registros

Antes dos bancos relacionais se popularizarem, isso era ouro.


Precisão decimal

Enquanto várias linguagens sofriam com arredondamentos, COBOL nasceu para dinheiro.

E dinheiro não aceita erro.


O VERDADEIRO PROBLEMA: O COBOL NASCEU PARA NEGÓCIOS

A palavra COBOL significa:

Common Business Oriented Language

Observe:

Não é:

  • Common Game Language

  • Common Scientific Language

  • Common Internet Language

É:

Business.

Negócios.

Empresas.

Contabilidade.

Folha de pagamento.

Seguros.

Finanças.

Faturamento.

Desde o nascimento, ele tinha um propósito extremamente específico.


ENQUANTO ISSO, O MUNDO MUDOU

Na década de 1960 isso era perfeito.

Mas nas décadas seguintes surgiram novos mercados.


Computação científica

FORTRAN dominou.


Sistemas operacionais

C dominou.


Inteligência Artificial

LISP dominou inicialmente.


Aplicações gráficas

C++


Internet

Java

PHP

Perl

JavaScript


Ciência de Dados

Python

R


O mundo começou a exigir coisas que nunca foram prioridade para o COBOL.


O COBOL NÃO FOI FEITO PARA SER "COOL"

Aqui existe um fator psicológico interessantíssimo.

Pense nos heróis da programação:

  • Linus Torvalds → C

  • Guido van Rossum → Python

  • Bjarne Stroustrup → C++

  • James Gosling → Java

Agora pense em COBOL.

A maioria das pessoas nem sabe quem foi Grace Hopper.

Grace Hopper ajudou a criar conceitos fundamentais que levariam ao COBOL.

Mas a linguagem nunca foi vendida como algo revolucionário.

Ela foi vendida como algo:

  • estável

  • corporativo

  • burocrático

E isso afasta jovens desenvolvedores.


O EFEITO "BANCO"

Imagine dois anúncios.

Linguagem A

"Crie jogos incríveis!"

Linguagem B

"Automatize cálculos atuariais."

Qual parece mais divertida?

Foi exatamente isso que aconteceu.

COBOL ficou associado a:

  • bancos

  • seguradoras

  • governos

  • sistemas legados

Enquanto outras linguagens ficaram associadas à inovação.


O ERRO DE MARKETING MAIS CARO DA HISTÓRIA

Durante os anos 80 e 90, universidades começaram a ensinar:

  • C

  • Pascal

  • C++

  • Java

COBOL desapareceu dos cursos.

A consequência foi devastadora.

Menos estudantes.

Menos projetos.

Menos comunidade.

Menos livros.

Menos ferramentas.

Menos conteúdo.

Menos adoção.

Criou-se um círculo vicioso.


O PROBLEMA DAS FERRAMENTAS

Vamos ser honestos.

Nos anos 90 era muito mais divertido programar Visual Basic do que COBOL.

Visual Basic tinha:

  • botões

  • janelas

  • eventos

Você arrastava componentes.

Tudo aparecia na tela.

COBOL continuava focado em:

OPEN INPUT CLIENTES
READ CLIENTES

O apelo visual era praticamente zero.


O MUNDO APAIXONOU-SE POR INTERFACES GRÁFICAS

Quando o Windows explodiu, surgiu uma nova geração de desenvolvedores.

Eles queriam construir:

  • telas

  • jogos

  • multimídia

COBOL não era o candidato natural.


O MAINFRAME PROTEGEU O COBOL

Aqui está a maior ironia.

O Mainframe foi simultaneamente:

  • a maior força do COBOL

  • e sua maior prisão

Sem Mainframe talvez COBOL tivesse desaparecido.

Mas graças ao Mainframe ele sobreviveu.

Por outro lado, o sucesso no Mainframe reduziu o incentivo para conquistar outros mercados.

Os bancos já estavam satisfeitos.

Por que mudar?


O FATOR ECONÔMICO

Imagine um banco.

Você possui:

  • 50 milhões de linhas COBOL

  • 40 anos de história

  • bilhões movimentados diariamente

Qual decisão é mais segura?

Opção A

Migrar tudo.

Opção B

Continuar usando COBOL.

A resposta é óbvia.


O EFEITO "SE ESTÁ FUNCIONANDO, NÃO MEXA"

Poucas linguagens tiveram a sorte de trabalhar em ambientes tão conservadores.

Um sistema bancário precisa:

  • estabilidade

  • previsibilidade

  • auditoria

Não precisa ser moderno.

Precisa funcionar.

E COBOL funciona.

Muito bem.


A CHEGADA DA INTERNET

Nos anos 90 surgiu a Web.

Foi uma nova corrida do ouro.

Linguagens correram para conquistar esse território.

  • Java

  • PHP

  • Perl

  • ASP

COBOL chegou depois.

Muito depois.

Quando chegou, o mercado já tinha donos.


O PROBLEMA DA COMUNIDADE

Uma linguagem vive ou morre pela comunidade.

Python possui:

  • milhões de usuários

  • milhares de bibliotecas

  • eventos globais

Java possui ecossistema gigantesco.

COBOL sempre teve uma comunidade menor.

Extremamente qualificada.

Mas menor.


O FATOR OPEN SOURCE

Outro golpe importante.

O movimento Open Source impulsionou:

  • Linux

  • Python

  • PHP

  • Perl

COBOL permaneceu muito ligado ao mundo corporativo.

Licenças caras.

Compiladores pagos.

Ferramentas empresariais.

Isso limitou sua expansão.


MAS EXISTE COBOL OPEN SOURCE

Hoje existe o fantástico:

GNUCobol

GnuCOBOL Official Project

Ele compila COBOL para C e roda em:

  • Linux

  • Windows

  • macOS

Mostrando que o COBOL continua vivo fora do Mainframe.


O COBOL É LENTO?

Outro mito.

Na verdade, muitas implementações COBOL são extremamente rápidas.

Especialmente em processamento transacional.

O problema nunca foi desempenho.


O COBOL É ANTIGO DEMAIS?

Também não.

Veja a ironia.

Hoje temos:

  • APIs REST

  • JSON

  • XML

  • Kafka

  • Containers

  • Docker

E o COBOL já conversa com tudo isso.

Inclusive o usuário Bellacosa Mainframe frequentemente explora integrações modernas entre COBOL, JSON, CICS Web Services e z/OS Connect.

O problema não é tecnológico.

É percepção de mercado.


O PARADOXO DO SUCESSO

O COBOL sofreu do mesmo problema que o DB2 Mainframe.

Ele ficou tão bom no que fazia que nunca precisou mudar radicalmente.

Enquanto outras linguagens lutavam para sobreviver, o COBOL já tinha conquistado o setor financeiro.


O QUE ACONTECERIA SE O COBOL FOSSE CRIADO HOJE?

Imagine uma linguagem com:

  • sintaxe legível

  • precisão decimal nativa

  • foco em regras de negócio

  • forte tipagem

  • excelente auditoria

Provavelmente seria vendida como:

  • FinTech Language

  • Banking Language

  • Enterprise Language

E talvez fosse considerada revolucionária.


O COBOL PERDEU A GUERRA?

Não.

Na verdade, ele venceu uma guerra diferente.

Enquanto milhares de linguagens nasceram e morreram, COBOL continua executando sistemas críticos após mais de seis décadas.

Poucas tecnologias na história conseguiram isso.


A VERDADE QUE POUCOS ADMITEM

Quando um programador Python cria um sistema hoje, ninguém sabe se ele existirá daqui a 30 anos.

Quando um programador COBOL cria um sistema bancário, existe uma boa chance de alguém ainda estar executando aquele código décadas depois.

Isso muda completamente a forma de projetar software.


A GRANDE LIÇÃO PARA OS PADAWANS

A pergunta correta não é:

"Por que COBOL ficou nichado no Mainframe?"

A pergunta correta é:

"Por que o Mainframe continuou sendo o melhor lugar para executar aquilo que o COBOL foi criado para fazer?"

Porque o COBOL nasceu para resolver problemas empresariais gigantescos.

E o Mainframe continua sendo a plataforma mais eficiente para executar esses processos com:

  • confiabilidade

  • segurança

  • disponibilidade

  • escalabilidade

  • integridade transacional

O COBOL não ficou preso ao Mainframe.

Na realidade, ele encontrou seu habitat natural.

As versões para DOS, Windows e Linux sempre existiram, continuam existindo e funcionam muito bem.

Mas fora do Mainframe ele precisava competir com centenas de linguagens.

Dentro do Mainframe ele se tornou rei.

E existe uma enorme diferença entre participar de uma competição e dominar um reino.

Mais de 65 anos depois de seu nascimento, o COBOL continua processando salários, aposentadorias, seguros, cartões de crédito, transferências bancárias e operações financeiras que sustentam boa parte da economia mundial.

Poucas linguagens podem dizer isso.

E talvez esse seja o maior paradoxo da computação:

O COBOL não conquistou todas as plataformas porque nunca precisou.

Ele já estava ocupado movendo o mundo. ☕🚀



quinta-feira, 4 de junho de 2026

A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS

 

Bellacosa Mainframe e o covid expondo problemas da divida tecnica

☕💣📋 A DÍVIDA TÉCNICA QUASE PAROU OS BANCOS — A COVID APERTOU ENTER E O SISTEMA REVELOU 40 ANOS DE PROBLEMAS ESCONDIDOS


O DIA EM QUE UM PROGRAMADOR COBOL JÚNIOR DESCOBRIU QUE O MAIOR BUG DO BANCO NÃO ESTAVA NO CÓDIGO

Imagine a seguinte situação.

Você acabou de entrar em um grande banco.

Recebe seu primeiro programa COBOL para manutenção.

Abre o membro no ISPF.

O programa possui:

  • 28.000 linhas

  • 134 COPYBOOKS

  • 742 parágrafos

  • Comentários da época do Plano Real

  • Um PERFORM THRU que ninguém entende

  • Um campo chamado WK-AREA1

  • Outro chamado WK-AREA2

  • Outro chamado WK-AREA3

E você pensa:

"Quem foi o maluco que escreveu isso?"

Então um analista veterano olha para você e responde:

— Eu.

E completa:

— Em 1998 aquilo era considerado moderno.

Nesse momento você acabou de conhecer um dos conceitos mais importantes da engenharia de software:

Dívida Técnica


O QUE É DÍVIDA TÉCNICA?

A melhor definição é simples.

Dívida técnica é quando uma decisão que economiza tempo hoje gera custos maiores amanhã.

Funciona exatamente como um empréstimo bancário.

Você pega dinheiro hoje.

Mas depois paga:

  • principal

  • juros

  • correção

  • multas

No software acontece a mesma coisa.

Você ganha velocidade agora.

Mas perde produtividade no futuro.


EXEMPLO COBOL CLÁSSICO

Imagine que em 1998 alguém criou:

IF AGENCIA = 1234
   MOVE 'SANTOS' TO CIDADE
END-IF

Parecia inofensivo.

Hoje existem:

  • 3.000 agências

  • dezenas de fusões

  • múltiplas marcas

Agora o código virou:

IF AGENCIA = 1234
...
ELSE IF AGENCIA = 2345
...
ELSE IF AGENCIA = 3456
...

O que era uma solução virou um problema.


COMO A DÍVIDA TÉCNICA NASCE?

Normalmente através de frases famosas.

Frase 1

"Depois a gente melhora."

Mentira.

Ninguém melhora.


Frase 2

"É só uma correção rápida."

Nunca é.


Frase 3

"O projeto fecha sexta-feira."

A dívida nasce quinta.


Frase 4

"Não mexe porque funciona."

O terror dos bancos.


OS TIPOS DE DÍVIDA TÉCNICA

1. Código

Programas difíceis de entender.

Exemplos:

  • GOTO excessivo

  • PERFORM THRU gigantes

  • variáveis sem significado

  • duplicação


2. Arquitetura

Problemas maiores.

Exemplos:

  • sistemas monolíticos

  • dependências excessivas

  • integrações frágeis


3. Dados

Muito comum em bancos.

Exemplos:

  • arquivos VSAM redundantes

  • tabelas DB2 duplicadas

  • dados inconsistentes


4. Processos

Pouco discutida.

Mas extremamente perigosa.

Exemplos:

  • deploy manual

  • testes manuais

  • documentação inexistente


COMO IDENTIFICAR DÍVIDA TÉCNICA?

Um júnior costuma perguntar:

"Como sei que existe dívida?"

Observe sintomas.


Sintoma 1

Mudanças simples levam semanas.


Sintoma 2

Toda alteração gera incidente.


Sintoma 3

Poucas pessoas entendem o sistema.


Sintoma 4

Ninguém quer mexer.


Sintoma 5

A frase mais perigosa:

"Esse programa é do fulano."

Quando o sistema tem dono humano, existe dívida.


MÉTRICAS IMPORTANTES

Agora entramos em uma área que diferencia profissionais comuns de profissionais de elite.

Você não gerencia aquilo que não mede.


1. COMPLEXIDADE CICLOMÁTICA

Criada por Thomas McCabe.

Mede quantos caminhos lógicos existem.

Exemplo:

IF A
   ...
ELSE
   ...
END-IF

Complexidade = 2

Agora imagine 300 IFs.

O número explode.

Quanto maior:

  • mais difícil testar

  • mais difícil manter

  • maior risco

Meta saudável:

  • abaixo de 10 excelente

  • até 20 aceitável

  • acima de 30 perigoso


2. LINHAS DE CÓDIGO

LOC (Lines of Code)

Não mede qualidade.

Mas mede tamanho.

Programa COBOL:

  • 500 linhas → simples

  • 5.000 linhas → atenção

  • 20.000 linhas → investigação


3. DUPLICAÇÃO DE CÓDIGO

Quanto código está repetido?

Exemplo:

Mesma regra de cálculo em:

  • cadastro

  • empréstimo

  • cartão

  • investimentos

Quando muda uma regra:

quatro programas precisam mudar.


4. COBERTURA DE TESTES

Quanto do sistema é validado?

Métrica:

Cobertura = código testado / código total

Quanto maior, melhor.


5. TEMPO MÉDIO DE CORREÇÃO

MTTR

Mean Time To Repair.

Quanto tempo leva para corrigir problemas.

Quanto menor:

melhor maturidade.


6. DEFEITOS POR RELEASE

Muito utilizada em bancos.

Pergunta simples:

Quantos incidentes surgem após implantação?


FERRAMENTAS QUE AJUDAM

Vamos ao arsenal.


IBM APPLICATION DISCOVERY

Conhecida como AD.

Excelente para:

  • dependências

  • impacto

  • análise de código

Mostra relacionamentos invisíveis.


IBM APPLICATION DELIVERY FOUNDATION

Ajuda em:

  • DevOps

  • testes

  • integração


SONARQUBE

Uma das mais famosas.

Analisa:

  • complexidade

  • duplicação

  • vulnerabilidades

Possui suporte para COBOL.


TOPAZ

Muito utilizada em ambientes Compuware/BMC.

Excelente para:

  • visualização

  • debugging

  • análise


ENDEVOR

Ajuda no controle de versões.

Embora não seja ferramenta de dívida técnica, ajuda a evitar que ela cresça.


GIT

Sim.

Programadores COBOL modernos usam Git.

O mundo mudou.


COMO REDUZIR DÍVIDA TÉCNICA?

Agora chegamos à parte prática.


PASSO 1

MAPEAR

Nunca saia corrigindo.

Primeiro descubra:

  • onde está

  • quanto existe

  • qual impacto


PASSO 2

CLASSIFICAR

Separe em:

Alta prioridade

Afeta negócio.

Média prioridade

Afeta produtividade.

Baixa prioridade

Apenas estética.


PASSO 3

ATACAR O TOPO

Use a regra 80/20.

Normalmente:

20% dos programas geram 80% dos problemas.

Comece por eles.


PASSO 4

REFATORAR

Refatorar significa:

melhorar sem alterar comportamento.

Exemplo:

Antes

MOVE 'S' TO WS-FLAG1

Depois

MOVE 'S' TO WS-CLIENTE-ATIVO

Mesmo resultado.

Melhor compreensão.


PASSO 5

REMOVER DUPLICAÇÃO

Regra de ouro.

Se existe em cinco lugares.

Transforme em um.


PASSO 6

DOCUMENTAR

A documentação mais barata é aquela escrita hoje.

A mais cara é aquela que será escrita daqui cinco anos.


PASSO 7

CRIAR APIs

Aqui entra a modernização.

Não destrua o COBOL.

Encapsule.

Exemplo:

Mobile
   |
API
   |
CICS
   |
COBOL
   |
DB2

O COBOL continua funcionando.

Mas agora conversa com o mundo moderno.


O PAPEL DA CLOUD

Muitos profissionais acreditam:

"Cloud substitui Mainframe."

Não.

A realidade é:

Cloud complementa Mainframe.

O mercado está migrando para:

Mainframe + APIs + Cloud + IA

Não:

Mainframe versus Cloud

EASTER EGG DA INDÚSTRIA

Você sabia?

Grande parte dos sistemas bancários mais críticos do planeta possui código executando há décadas.

Alguns módulos possuem mais idade que muitos programadores que fazem manutenção neles.


CURIOSIDADE

Em muitos bancos existem programas COBOL executados diariamente há mais de 30 anos sem interrupção significativa.

Pouquíssimas tecnologias no mundo podem afirmar isso.


A REGRA DOS ESCOTEIROS

Uma das melhores técnicas contra dívida técnica.

Conhecida como:

Boy Scout Rule

"Deixe o código mais limpo do que encontrou."

Você corrige um bug.

Aproveite para:

  • melhorar nomes

  • remover comentários obsoletos

  • eliminar duplicações

Pequenas melhorias acumulam enormes resultados.


O ERRO QUE TODO JÚNIOR COMETE

Querer reescrever tudo.

Não faça isso.

Sistemas bancários existem para:

  • processar pagamentos

  • movimentar bilhões

  • atender clientes

Não para serem bonitos.

Primeiro entenda.

Depois melhore.

Por último modernize.


O CAMINHO DE EVOLUÇÃO PROFISSIONAL

Júnior:

"Como funciona?"

Pleno:

"Como melhorar?"

Sênior:

"Como evitar que o problema volte?"

Arquiteto:

"Como impedir que o problema exista?"


☕🦠💣 QUANDO A COVID FEZ O IPL DO PLANETA E REVELOU TODOS OS ABENDS ESCONDIDOS DOS BANCOS

Até 2020 muitos bancos acreditavam que estavam preparados para o futuro.

Possuíam:

  • Internet Banking

  • Aplicativos móveis

  • Chatbots

  • APIs

  • Transformação Digital nos PowerPoints

Então chegou a COVID.

E a realidade apareceu.


O TESTE DE STRESS QUE NINGUÉM PLANEJOU

Durante décadas os bancos planejavam crescimento gradual.

De repente aconteceu:

Milhões de clientes
tentando acessar
os sistemas ao mesmo tempo

O equivalente em mainframe seria:

100.000 jobs
entrando na fila
simultaneamente

O QUEBROU?

Curiosamente, muitas vezes não foi o COBOL.

Nem o CICS.

Nem o DB2.

Foi a camada moderna.

Por exemplo:

  • Portais Web

  • Gateways API

  • Aplicativos móveis

  • Centrais de atendimento

Os sistemas core continuavam funcionando.

Mas os canais de acesso colapsaram.


O DIA EM QUE O BANCO DESCOBRIU SUA DÍVIDA TÉCNICA

Muitas instituições descobriram:

  • Processos manuais escondidos

  • Dependência excessiva de funcionários específicos

  • Sistemas sem escalabilidade

  • Arquiteturas ultrapassadas

A pandemia funcionou como um scanner de vulnerabilidades em escala mundial.


☁️ A NUVEM NÃO É UMA MÁQUINA. É UMA ESTRATÉGIA.

Um dos maiores erros dos iniciantes é pensar:

Cloud = Servidor em outro lugar

Não.

Cloud é uma mudança de modelo operacional.


O QUE A NUVEM OFERECE?

Imagine que amanhã o banco precise processar:

10 vezes mais transações

No modelo tradicional:

  • Comprar servidores

  • Instalar servidores

  • Configurar servidores

Meses de trabalho.


NA NUVEM

Precisa de mais capacidade?

Adiciona.

Precisa de menos?

Remove.


A NUVEM REDUZ DÍVIDA TÉCNICA?

Resposta curta:

Não.


RESPOSTA LONGA

A nuvem não elimina dívida técnica.

Mas torna muito mais fácil combatê-la.

Exemplo:

Antes:

Sistema monolítico
30.000 programas

Depois:

Microserviços
APIs
Containers

Agora você consegue modernizar partes isoladas.


O PADRÃO QUE ESTÁ DOMINANDO OS BANCOS

O mercado financeiro está migrando para:

Cloud
    |
APIs
    |
Mainframe
    |
DB2

Não:

Cloud substituindo Mainframe

Mas:

Cloud consumindo Mainframe

Essa diferença é gigantesca.


O STRANGLER PATTERN

Um dos segredos da modernização bancária.

Ao invés de destruir:

Sistema COBOL

Você faz:

Nova API

Depois:

Novo serviço

Depois:

Novo canal digital

E o legado vai sendo cercado gradualmente.


👨‍💼 O PROBLEMA QUE NINGUÉM GOSTA DE DISCUTIR: RH

A parte mais interessante da entrevista da IBM talvez seja esta:

A maior dívida técnica não é financeira.

É humana.


O PROGRAMA COBOL QUE APOSENTOU O FUNCIONÁRIO

Imagine:

Programa:

PAGBOL01

Criado em:

1994

Quem entende?

Uma pessoa.


O DIA DO DESASTRE

Essa pessoa:

  • aposenta

  • muda de empresa

  • entra em férias

Pronto.

Agora existe um risco operacional.


O FATOR ÔNIBUS

Métrica famosa.

Pergunta:

Quantas pessoas precisam desaparecer para que o projeto pare?

Se a resposta for:

1

Você possui um problema grave.


O QUE OS JOVENS DESENVOLVEDORES PROCURAM?

A nova geração busca:

  • Git

  • APIs

  • DevOps

  • Cloud

  • Automação

  • CI/CD

Não necessariamente porque são modismos.

Mas porque aumentam produtividade.


O ERRO DOS GESTORES

Muitos acreditam:

"Os jovens não querem aprender COBOL."

Errado.

O que eles não querem é:

Trabalhar em caos.

Existe uma enorme diferença.


UM COBOL MODERNO É ATRAENTE

Imagine um ambiente com:

  • Git

  • VS Code

  • Zowe

  • APIs REST

  • Jenkins

  • SonarQube

E atrás disso:

COBOL
CICS
DB2

O profissional moderno trabalha feliz.


UM COBOL ANTIGO É REPELENTE

Agora imagine:

  • documentação inexistente

  • deploy manual

  • FTP

  • planilhas Excel

  • mudanças sem controle

O problema não é COBOL.

É a cultura.


O CUSTO INVISÍVEL DA DÍVIDA TÉCNICA

Os gestores normalmente medem:

  • hardware

  • software

  • licenças

Mas esquecem:

  • turnover

  • treinamento

  • conhecimento perdido

Esses custos podem superar os custos tecnológicos.


O CICLO VICIOSO

A dívida técnica cria:

Sistema ruim
      ↓
Pouca produtividade
      ↓
Mais pressão
      ↓
Mais atalhos
      ↓
Mais dívida técnica
      ↓
Mais pessoas saem
      ↓
Menos conhecimento
      ↓
Mais dívida técnica

É um círculo destrutivo.


O CICLO VIRTUOSO

A modernização cria:

Melhor arquitetura
       ↓
Mais produtividade
       ↓
Menos incidentes
       ↓
Mais inovação
       ↓
Mais satisfação
       ↓
Melhor retenção
       ↓
Mais conhecimento
       ↓
Menos dívida técnica

A GRANDE LIÇÃO PARA O PROGRAMADOR COBOL JÚNIOR

Quando você ouvir a expressão:

"Precisamos migrar para a nuvem."

Não pense em servidores.

Pense em:

  • agilidade

  • automação

  • integração

  • APIs

  • escalabilidade

  • experiência do desenvolvedor

Quando ouvir:

"Precisamos reduzir dívida técnica."

Não pense apenas em código.

Pense em:

  • pessoas

  • conhecimento

  • processos

  • documentação

  • cultura

E quando ouvir:

"Precisamos modernizar o mainframe."

Lembre-se:

Os maiores bancos do mundo não estão abandonando COBOL.

Eles estão cercando COBOL com tecnologias modernas para que ele continue entregando valor pelos próximos 30 anos.


CONCLUSÃO

A maior lição sobre dívida técnica é surpreendente.

O problema raramente é COBOL.

O problema quase sempre é falta de gestão.

Um programa COBOL de 1985 pode ser extremamente moderno se possuir:

  • documentação

  • testes

  • APIs

  • observabilidade

  • versionamento

  • arquitetura bem definida

Da mesma forma, uma aplicação criada ontem pode nascer cheia de dívida técnica.

Lembre-se sempre:

Dívida técnica não é idade.

Dívida técnica é descuido acumulado.

E existe uma enorme diferença entre um sistema antigo e um sistema mal cuidado.

O programador COBOL que entender essa diferença deixa de ser apenas um mantenedor de código legado e passa a ser um verdadeiro engenheiro responsável por preservar, modernizar e evoluir alguns dos sistemas mais importantes do planeta.