 |
| Bellacosa Mainframe e a golden hammer rules |
☕ Um Café no Bellacosa Mainframe
Golden Hammer Rules sem Mistérios
Quando um Programador COBOL Descobriu que Nem Todo Problema da Matrix Deve Ser Resolvido com a Mesma Ferramenta
"Se tudo o que você possui é um martelo dourado, a Matrix fará você acreditar que todos os problemas são pregos."
Prólogo — O Arsenal da Nebuchadnezzar
A Nebuchadnezzar atravessa silenciosamente os túneis subterrâneos de Zion.
Neo acaba de retornar de uma missão.
Na tela principal aparecem dezenas de chamados críticos.
Morpheus aponta para o painel.
— Precisamos resolver tudo isso antes que os Sentinelas encontrem nossa posição.
Neo observa a lista.
Lentidão no banco de dados.
Falha de autenticação.
Erro em uma API REST.
ABEND S0C7 em um programa COBOL.
Saturação da fila MQ.
Gargalo em processamento batch.
Interface gráfica travando.
Antes que alguém diga qualquer coisa...
Cypher responde:
— Fácil.
Vamos resolver tudo em Java.
Trinity balança a cabeça.
Logo outro programador interrompe.
— Não.
Tudo deveria ser Python.
Um arquiteto sorri.
— Na verdade...
Tudo deveria virar microsserviço.
O operador do mainframe responde.
— Nada disso.
COBOL resolve tudo.
Morpheus olha para Neo.
— Acabamos de encontrar o Golden Hammer.
O que é Golden Hammer?
Golden Hammer (Martelo Dourado) é um dos antipadrões mais conhecidos da Engenharia de Software.
Ele descreve uma situação muito comum:
Quando uma pessoa insiste em usar sempre a mesma tecnologia, linguagem, arquitetura ou ferramenta para resolver qualquer problema, independentemente de existir uma solução mais adequada.
É o famoso pensamento:
"Se tudo o que você possui é um martelo, todos os problemas parecem pregos."
A origem do conceito
O conceito nasceu inspirado em uma frase atribuída ao psicólogo Abraham Maslow, na década de 1960.
Ele escreveu:
"I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."
("Suponho que seja tentador, se a única ferramenta que você possui é um martelo, tratar tudo como se fosse um prego.")
Décadas depois, a Engenharia de Software adotou essa ideia.
O "martelo" tornou-se uma tecnologia favorita.
O "prego" virou qualquer problema.
Matrix explica isso perfeitamente
Imagine que Neo acabou de aprender Kung Fu.
Ele está empolgado.
Agora tenta resolver tudo usando artes marciais.
Portas trancadas?
Kung Fu.
Computador travado?
Kung Fu.
Problema de criptografia?
Kung Fu.
Banco de dados?
Kung Fu.
Morpheus sorri.
— Neo...
Saber usar uma ferramenta não significa que ela seja adequada para tudo.
Na Engenharia de Software acontece exatamente isso.
O Golden Hammer no Mainframe
Imagine um programador COBOL extremamente experiente.
Trinta anos de carreira.
Excelente profissional.
Recebe um novo desafio.
Criar um chatbot baseado em IA Generativa.
Sua primeira resposta:
"Vamos fazer tudo em COBOL."
Será que COBOL consegue participar?
Claro.
Mas será que deve implementar o modelo de linguagem?
Provavelmente não.
COBOL pode integrar.
Python pode treinar modelos.
Java pode expor APIs.
MQ pode transportar mensagens.
Cada ferramenta possui seu papel.
Outro exemplo
Agora imagine o contrário.
Um desenvolvedor recém-chegado diz:
"Vamos reescrever todo o core bancário em Node.js."
Pode parecer moderno.
Mas será sensato substituir milhões de linhas COBOL altamente estáveis apenas porque a tecnologia está na moda?
Também não.
Golden Hammer funciona nos dois sentidos.
O nascimento do Martelo Dourado
Como alguém desenvolve esse comportamento?
Normalmente acontece assim.
O profissional aprende profundamente uma tecnologia.
Ela resolve vários problemas.
Recebe promoções.
Ganha reconhecimento.
Depois de alguns anos...
começa a enxergar aquela ferramenta como solução universal.
Sem perceber...
entra na Matrix do Golden Hammer.
O efeito psicológico
Existe um fenômeno chamado:
Comfort Zone Bias
Nosso cérebro prefere utilizar aquilo que já domina.
É muito mais confortável escrever:
COBOL
do que aprender Rust.
Muito mais confortável usar:
Python
do que entender CICS.
Muito mais confortável usar:
Java
do que estudar Db2.
A Matrix adora conforto.
Exemplo COBOL
Projeto:
Integração com OpenAI.
O arquiteto propõe:
Python.
REST.
JSON.
OAuth.
HTTPS.
Mas alguém insiste:
"Vamos implementar um parser manual de JSON em COBOL para tudo."
Será que funciona?
Sim.
É a melhor solução?
Nem sempre.
Exemplo inverso
Outro projeto.
Processamento de cinquenta milhões de transações diárias.
Alguém sugere:
"Vamos migrar tudo para microsserviços."
Pergunta importante.
Por quê?
Resposta:
"Porque todo mundo está fazendo."
Isso também é Golden Hammer.
Matrix Reloaded
O Arquiteto conhece milhares de linguagens.
Ele nunca pergunta:
"Qual tecnologia eu gosto?"
Ele pergunta:
"Qual tecnologia resolve melhor este problema?"
Essa é a pergunta que diferencia um arquiteto de um fanático.
O Agente Smith representa o fanatismo
Smith acredita existir apenas uma forma correta.
Todos devem ser iguais.
Mesmo comportamento.
Mesmo pensamento.
Mesmo padrão.
Golden Hammer funciona exatamente assim.
Existe apenas:
uma linguagem.
uma arquitetura.
uma solução.
Na vida real...
isso nunca é verdade.
O perigo para Programadores COBOL
Alguns profissionais acreditam:
"Tudo deve ser COBOL."
Outros:
"Tudo deve ser Java."
Outros:
"Tudo deve ser Python."
Outros:
"Tudo deve ser IA."
Nenhum extremo é saudável.
O COBOL continua importante?
Absolutamente.
Ele continua sendo excelente para:
processamento batch
regras de negócio
alta disponibilidade
transações financeiras
integração com Db2
CICS
sistemas críticos
Mas isso não significa que deva resolver tudo sozinho.
O Arsenal da Frota
Imagine a Frota de Zion.
Ela possui:
EMP.
Hovercraft.
Sentinelas capturadas.
Explosivos.
Robôs.
Cada equipamento possui uma função.
Nenhum substitui todos os outros.
Software também.
Ferramenta certa para o problema certo
| Problema | Melhor opção (exemplo) |
|---|---|
| Processamento financeiro | COBOL |
| Interface Web | React |
| IA | Python |
| Integração | Java / Go |
| Mensageria | MQ / Kafka |
| Persistência | Db2 |
| Busca textual | Elasticsearch |
| Automação | Ansible |
| Containers | Docker |
Nenhuma tecnologia vence todas.
Como identificar Golden Hammer?
Faça perguntas.
Estou escolhendo isso porque:
É a melhor solução?
Ou
Porque é a única que conheço?
Essa pergunta muda carreiras.
Sinais de alerta
Frases clássicas.
"COBOL resolve tudo."
"Java resolve tudo."
"Python resolve tudo."
"IA resolve tudo."
"Microsserviços resolvem tudo."
"Kubernetes resolve tudo."
Sempre que alguém usa:
"Tudo"
desconfie.
Os riscos
Arquitetura inadequada
Ferramenta errada.
Problema certo.
Resultado ruim.
Custos elevados
Tecnologia inadequada gera desperdício.
Performance
Nem toda linguagem foi feita para todas as cargas.
Manutenção
Equipe sofre.
Escalabilidade
Nem sempre acompanha crescimento.
Dependência tecnológica
Empresa fica presa.
O Golden Hammer e o hype
A Matrix também cria modismos.
Hoje:
IA.
Ontem:
Blockchain.
Antes:
Microservices.
Antes:
SOA.
Antes:
XML.
Antes:
CORBA.
Antes:
Cliente-Servidor.
Toda geração acredita ter encontrado a solução definitiva.
Nenhuma encontrou.
Curiosidade
Empresas maduras raramente perguntam:
"Qual tecnologia usamos?"
Perguntam:
"Qual problema estamos resolvendo?"
Essa diferença parece pequena.
Mas muda completamente a arquitetura.
O papel do Arquiteto
O verdadeiro arquiteto conhece muitas ferramentas.
Não porque gosta delas.
Mas porque precisa escolher.
Escolher exige comparação.
Matrix e o Escolhido
Neo não vence porque usa apenas força.
Ele vence porque aprende.
Aprende:
quando lutar.
quando fugir.
quando negociar.
quando confiar.
Tecnologia também.
Como evitar o Golden Hammer?
Aprenda continuamente
Quanto maior seu repertório...
menor o fanatismo.
Compare alternativas
Nunca escolha a primeira solução.
Faça provas de conceito
POCs reduzem riscos.
Escute especialistas
Ninguém domina tudo.
Entenda o negócio
Tecnologia serve ao negócio.
Não o contrário.
O COBOL Padawan
Você não precisa abandonar COBOL.
Muito pelo contrário.
Domine COBOL profundamente.
Mas aprenda também:
APIs
JSON
Python
Git
Docker
Linux
SQL
MQ
Cloud
IA
Assim seu martelo vira uma caixa de ferramentas.
Atenção!
Existe um erro comum.
Confundir:
Especialização
com
Fanatismo.
Ser especialista em COBOL é excelente.
Acreditar que COBOL resolve absolutamente tudo...
não.
Aplicabilidade
Golden Hammer aparece em:
Arquitetura
Infraestrutura
Banco de Dados
IA
Cloud
Segurança
DevOps
Mainframe
Mobile
Web
É universal.
Curiosidades
IBM utiliza dezenas de linguagens diferentes internamente.
Google também.
Amazon.
Microsoft.
Meta.
Nenhuma empresa gigante aposta em apenas uma tecnologia.
Todas trabalham com ecossistemas.
O Ensinamento do Oráculo
O Oráculo entrega uma caixa de ferramentas para Neo.
Dentro existem:
uma chave inglesa.
um alicate.
um martelo.
uma chave Phillips.
uma chave Allen.
Neo pergunta.
"Qual delas é a melhor?"
Ela responde.
"Depende do parafuso."
Essa talvez seja a melhor definição de Arquitetura de Software.
Erros comuns
Escolher tecnologia por moda.
Escolher tecnologia por preferência pessoal.
Ignorar restrições do negócio.
Reescrever sistemas estáveis sem necessidade.
Recusar novas ferramentas por orgulho.
Adotar ferramentas novas sem avaliar maturidade.
Lições para um Programador COBOL Padawan
No universo IBM Z, você trabalhará com sistemas que combinam COBOL, CICS, Db2, MQ, APIs REST, Java, Python, Zowe, Ansible e ferramentas de observabilidade. Um bom profissional entende que essas tecnologias não competem entre si; elas se complementam.
Seu objetivo não deve ser provar que COBOL é superior a Java, ou que Python é melhor que COBOL. Seu objetivo é entregar uma solução segura, eficiente, sustentável e adequada ao problema de negócio.
Quanto maior seu repertório técnico, maior será sua capacidade de tomar decisões equilibradas.
Conclusão — A Verdadeira Escolha Fora da Matrix
No final de Matrix Revolutions, Neo compreende que vencer não depende de força bruta, mas de compreender o sistema como um todo.
Na Engenharia de Software acontece exatamente o mesmo.
O profissional que enxerga apenas uma linguagem, um framework ou uma arquitetura está preso dentro de sua própria Matrix. Seu "martelo dourado" limita sua visão e faz com que qualquer desafio pareça exigir exatamente a mesma solução.
O verdadeiro Arquiteto da Frota Bellacosa Mainframe aprende uma lição diferente:
COBOL não substitui Python.
Python não substitui COBOL.
Microsserviços não substituem Mainframes.
Mainframes não eliminam a necessidade de APIs.
IA não elimina engenharia de software.
Cada ferramenta possui seu momento.
Cada tecnologia possui seu propósito.
Cada decisão deve ser guiada pelo problema de negócio, pelos requisitos não funcionais, pelos riscos e pelo contexto operacional.
Porque existe uma frase que todo Programador COBOL Padawan deveria gravar em sua memória:
"O melhor engenheiro não é aquele que possui o maior martelo. É aquele que sabe exatamente quando guardá-lo e escolher outra ferramenta."
Esse é o caminho para sair da Matrix do Golden Hammer e evoluir para um verdadeiro Arquiteto de Sistemas.
