 |
| Bellacosa Mainframe e o lobo roxo da Faria Lima |
☕ Um Café no Bellacosa Mainframe
O Lobo Roxo da Faria Lima: COBOL, Nubank e o Dia em que uma Startup Entrou no Salão dos Bancos e Descobriu que os Gigantes Tinham um Problema Chamado Fricção
💳 Como um cartão roxo, um aplicativo e uma arquitetura digital desafiaram Itaú, Bradesco, Santander, Banco do Brasil, Caixa e companhia — e o que um programador COBOL iniciante pode aprender com essa história antes de tentar reescrever o mundo em microsserviços
Imagine a cena.
Um enorme salão de operações financeiras.
Telas piscando.
Gráficos subindo e descendo.
Telefones tocando.
Executivos engravatados dizendo coisas como:
— Liquida isso antes do fechamento.
— Aumenta o limite da carteira.
— Quero essa posição zerada antes do almoço.
— Quanto temos de exposição?
No fundo da sala existe uma enorme porta de aço.
Nela está escrito:
CORE BANKING
AUTHORIZED PERSONNEL ONLY
Atrás daquela porta existem décadas de tecnologia bancária.
COBOL.
CICS.
Db2.
IMS.
MQ.
JCL.
VSAM.
RACF.
Batch noturno.
Arquivos gigantes.
Processamento de milhões de transações.
Sistemas que funcionavam quando muitos fundadores de fintechs ainda estavam aprendendo a andar.
Na mesa principal estão sentados os gigantes.
Banco do Brasil.
Caixa Econômica Federal.
Bradesco.
Itaú.
Santander.
Cada um com décadas — alguns com séculos — de história, capital, infraestrutura, clientes, agências, funcionários e sistemas.
Então entra alguém segurando um pequeno cartão roxo.
Nenhuma agência.
Nenhum prédio gigantesco.
Nenhuma tradição centenária.
Nenhum gerente esperando atrás de uma mesa de madeira.
Apenas um smartphone.
O pessoal da sala olha.
Um executivo pergunta:
— E você é quem?
A resposta:
— Nubank.
Silêncio.
Outro executivo ri.
— Banco?
— Mais ou menos.
— Quantas agências?
— Nenhuma.
— Quantos caixas?
— Nenhum.
— Então o que você tem?
O cartão roxo sobe lentamente.
— Um aplicativo.
Provavelmente alguém teria mandado o rapaz procurar a recepção.
E esse é justamente o começo da história.
Porque o Nubank não entrou no mercado bancário brasileiro tentando construir um banco tradicional um pouco melhor.
Ele entrou questionando uma premissa muito mais perigosa:
E se várias coisas que nós consideramos parte natural de um banco existirem apenas porque sempre foram feitas daquele jeito?
Para um programador COBOL iniciante, essa pergunta vale ouro.
Não porque COBOL seja velho.
Mas porque sistemas corporativos acumulam, ao longo das décadas, uma enorme quantidade de decisões.
Algumas são brilhantes.
Algumas continuam essenciais.
Algumas existem porque ninguém ousou perguntar por quê.
E algumas continuam ali simplesmente porque alterar aquilo custaria tanto que todo mundo prefere fingir que não percebeu.
Pegue o café.
Hoje vamos falar de bancos.
Mas, principalmente, vamos falar de sistemas.
Capítulo 1 — O mercado impossível
Imagine que você estivesse montando uma startup em 2013.
Alguém apresenta a ideia:
Vamos criar uma instituição financeira no Brasil.
Qualquer pessoa minimamente racional poderia responder:
— Excelente. E depois vamos fabricar aviões para competir com Boeing e Airbus?
O mercado brasileiro já possuía gigantes.
Banco do Brasil.
Caixa.
Bradesco.
Itaú.
Santander.
Bancos regionais.
Bancos médios.
Cooperativas.
Financeiras.
Administradoras de cartão.
Cada um com clientes, capital, tecnologia e décadas de conhecimento regulatório.
Era aparentemente um mercado horrível para entrar.
Só que existe uma diferença importante entre:
mercado competitivo
e:
mercado satisfatório para o consumidor
Essas coisas não são iguais.
Um mercado pode ter muitos concorrentes e, mesmo assim, oferecer experiências muito semelhantes.
Esse era um dos grandes pontos do sistema bancário tradicional.
O consumidor frequentemente encontrava:
tarifa
fila
agência
formulário
assinatura
telefone
gerente
burocracia
espera
O banco podia ser tecnologicamente sofisticadíssimo por trás.
Mas para o cliente?
Às vezes parecia 1987.
E aqui aparece uma primeira lição fundamental para quem está começando em COBOL.
Backend excelente não garante experiência excelente.
Você pode ter:
99,999% disponibilidade
no core.
Pode processar:
10 milhões de transações
durante a madrugada.
Pode ter:
RACF
CICS
DB2
IMS
GDG
SMF
WLM
funcionando perfeitamente.
Mas se o usuário precisar preencher três formulários, telefonar cinco vezes e esperar 40 minutos para resolver alguma coisa, ele não enxerga sua arquitetura maravilhosa.
Ele enxerga sofrimento.
O Nubank encontrou espaço justamente nessa distância.
Capítulo 2 — O inimigo não era o mainframe
Aqui existe um erro que aparece frequentemente quando se fala de fintech.
Alguém diz:
Fintech venceu porque banco tradicional usa mainframe.
Calma.
Não.
Muito pelo contrário.
Os mainframes dos grandes bancos são parte da razão pela qual essas instituições conseguem operar em enorme escala.
Um IBM Z pode processar volumes absurdos de transações com confiabilidade extraordinária.
COBOL continua executando grande parte da economia mundial porque resolve muito bem problemas transacionais.
Portanto:
MAINFRAME != PROBLEMA
O verdadeiro problema era frequentemente:
PROCESSO + ORGANIZAÇÃO + FRICÇÃO + HISTÓRIA
Veja a diferença.
O banco tradicional tinha algo conceitualmente parecido com:
CLIENTE
|
v
AGÊNCIA
|
v
GERENTE
|
v
SISTEMA DE ATENDIMENTO
|
v
MIDDLEWARE
|
v
CORE BANKING
O Nubank podia imaginar desde o início:
CLIENTE
|
v
SMARTPHONE
|
v
APLICAÇÃO
|
v
SERVIÇOS
|
v
PLATAFORMA FINANCEIRA
Não significa que o segundo modelo seja magicamente simples.
Há dezenas de problemas escondidos ali:
segurança;
KYC;
antifraude;
crédito;
liquidação;
bandeiras;
compliance;
regulação;
cobrança;
observabilidade;
contingência;
reconciliação.
Mas existe uma vantagem brutal:
o sistema nasceu pensando no canal digital como canal principal.
Isso é diferente de pegar um sistema construído durante décadas e acrescentar:
IF CHANNEL = MOBILE
PERFORM DIGITAL-FLOW
END-IF.
Sim, COBOLzeiro.
O mundo inteiro eventualmente vira um IF.
Capítulo 3 — O smartphone virou agência bancária
Um dos fatores decisivos do sucesso do Nubank foi timing.
O smartphone estava deixando de ser luxo.
Estava virando infraestrutura social.
De repente milhões de pessoas carregavam no bolso:
tela
câmera
internet
GPS
autenticação
notificações
aplicativos
Tudo isso em um único dispositivo.
Antes, para construir presença nacional, um banco precisava de prédios.
Agências.
Funcionários.
Terminais.
Caixas eletrônicos.
Segurança.
Transporte de numerário.
Infraestrutura física.
O smartphone alterou radicalmente essa equação.
A agência podia ser:
+-------------------+
| |
| 📱 |
| |
+-------------------+
O cliente não precisava ir ao banco.
O banco passava a ir com o cliente.
Essa mudança parece óbvia hoje.
Mas quase toda inovação parece óbvia depois que alguém faz.
Easter egg nº 1
Existe uma frase famosa atribuída ao mundo da tecnologia:
A melhor interface é aquela que desaparece.
No caso bancário, ocorreu algo ainda mais estranho.
A agência inteira começou a desaparecer.
Capítulo 4 — O cartão roxo era um cavalo de Troia
Agora chegamos a uma das decisões mais inteligentes.
O Nubank não tentou inicialmente convencer o brasileiro a transferir toda a vida financeira.
Imagine a proposta:
Feche sua conta no banco onde recebe salário há quinze anos, transfira seus investimentos e venha para uma startup desconhecida.
Resposta natural:
RETURN-CODE = 12
Mas:
Quer experimentar um cartão sem anuidade controlado por aplicativo?
Muito mais fácil.
Esse é um princípio importantíssimo de produto.
Reduza o tamanho da primeira decisão.
O Nubank entrou com algo relativamente simples:
CARTÃO
Depois podia expandir.
É praticamente uma estratégia de:
LAND
AND
EXPAND
Primeiro:
cartão
Depois:
conta
Depois:
Pix
Depois:
empréstimos
Depois:
investimentos
Depois:
seguros
E assim sucessivamente.
O cartão foi quase um:
ENTRY PROGRAM
do ecossistema Nubank.
COBOLzeiros entenderão imediatamente.
Você não chama todo o sistema.
Você chama um ponto de entrada.
Capítulo 5 — O Nubank descobriu o poder do segundo banco
Esse detalhe é gigantesco.
O Nubank não precisava inicialmente substituir Itaú, Bradesco ou Banco do Brasil.
Ele podia coexistir.
Um cliente poderia ter:
SALÁRIO ---------> ITAÚ
POUPANÇA --------> CAIXA
FINANCIAMENTO ---> SANTANDER
CARTÃO ----------> NUBANK
Isso eliminava uma barreira enorme:
switching cost.
Trocar completamente de banco pode ser traumático.
Experimentar um segundo cartão não.
Então milhões de pessoas podiam simplesmente testar.
Se gostassem, aumentavam o relacionamento.
É quase como instalar um programa novo sem desinstalar o antigo.
INSTALL NUBANK
WITHOUT DELETE BANCO-ANTERIOR
A estratégia foi brilhante porque reduziu o medo do consumidor.
Capítulo 6 — UX virou arma competitiva
Durante décadas, bancos venderam sobretudo:
segurança
solidez
tradição
patrimônio
confiança
O Nubank adicionou outra palavra:
experiência
Aplicativo bonito.
Informações claras.
Notificações imediatas.
Controle do cartão.
Atendimento pelo próprio aplicativo.
Linguagem menos burocrática.
Parece pouco?
Não é.
Em software corporativo existe um fenômeno curioso.
Às vezes gastamos:
R$ 100 milhões
melhorando sistemas internos.
Mas uma mudança de três telas altera dramaticamente a percepção do usuário.
Isso é uma lição fundamental.
O cliente não interage com arquitetura.
Ele interage com interfaces.
Você pode ter por trás:
COBOL
Assembler
Java
C
DB2
Kafka
MQ
Cloud
O cliente não se importa.
Ele quer apertar:
PAGAR
e receber:
PAGO
Se der erro, aí todo mundo passa a descobrir sua arquitetura.
É como eletricidade.
Ninguém pergunta qual transformador alimenta a geladeira.
Até faltar luz.
Capítulo 7 — O cartão roxo virou símbolo
Branding também importou enormemente.
Bancos tradicionais frequentemente usavam comunicação séria.
Executivos.
Ternos.
Prédios.
Famílias felizes financiando casas.
O Nubank apareceu com:
ROXO
Uma escolha visual extremamente diferenciada.
O cartão virou objeto de conversa.
E isso gerou algo extraordinário:
pessoas começaram a falar voluntariamente sobre uma instituição financeira.
Pense no absurdo.
Imagine uma conversa em 2015:
— Cara, chegou meu cartão!
— Qual?
— Nubank.
— O roxinho?
Marketing perfeito.
O produto carregava a marca fisicamente dentro da carteira do cliente.
Cada vez que alguém pagava uma conta:
DISPLAY "NUBANK"
Capítulo 8 — O convite criou escassez
Nos primeiros tempos havia fila.
Convites.
Expectativa.
E isso cria um mecanismo psicológico curioso.
Se alguma coisa parece difícil de conseguir, ela parece mais desejável.
É o velho truque do mercado financeiro:
DEMANDA > OFERTA
Então acontecia:
— Você já tem Nubank?
— Ainda não.
— Posso te mandar convite.
Pronto.
O cliente virou canal de aquisição.
Hoje chamaríamos isso de:
REFERRAL
Mas na prática era algo ainda melhor:
marketing social.
A propaganda vinha de alguém conhecido.
Não de um comercial de televisão.
Capítulo 9 — O custo de crescimento mudou
Agora vamos para arquitetura e economia.
Banco tradicional cresceu historicamente construindo:
AGÊNCIA
|
+-- imóvel
+-- funcionários
+-- segurança
+-- gerente
+-- caixa
+-- telecomunicação
+-- manutenção
+-- estrutura administrativa
Cada expansão geográfica significava infraestrutura física.
Um banco digital muda parcialmente a equação.
Novo cliente:
DOWNLOAD
|
v
CADASTRO
|
v
IDENTIFICAÇÃO
|
v
ANÁLISE
|
v
CONTA
Isso não significa custo zero.
Nunca significa custo zero.
Existem:
cloud
datacenter
fraude
atendimento
bandeira
processamento
compliance
capital
crédito
cobrança
segurança
Mas o custo marginal assume outra forma.
Essa diferença permite crescer muito rapidamente.
Se dez milhões de pessoas baixarem um aplicativo, você não precisa construir dez milhões de agências.
Seu problema muda.
Agora é:
SCALABILITY
E aí começa outra guerra.
Capítulo 10 — Escalar também dói
Startup tem uma palavra favorita:
scale
Todo mundo quer escalar.
Pouca gente fala da parte divertida.
Quando você escala, tudo que era pequeno vira grande.
Um erro de:
0,01%
parece irrelevante.
Até você ter cem milhões de operações.
Então:
100.000.000 * 0,0001 = 10.000
Dez mil problemas.
Bem-vindo ao mundo real.
COBOLzeiro, guarde essa lição:
sistemas financeiros não podem pensar apenas em funcionalidade; precisam pensar em volume.
Um programa que funciona perfeitamente com:
100 registros
pode virar desastre com:
100 milhões
É por isso que bancos adoram:
performance
capacity planning
WLM
SMF
RMF
batch window
index
partition
Escala transforma detalhes em incidentes.
Capítulo 11 — Dados: o combustível secreto
No começo, um banco tradicional possuía enorme vantagem.
Décadas de histórico.
Milhões de clientes.
Modelos de crédito.
Informações de comportamento.
O Nubank começou pequeno.
Mas conforme ganhou clientes passou a acumular dados.
Imagine:
valor da compra
horário
estabelecimento
pagamentos
atrasos
limites
movimentação
renda
comportamento
frequência
Com escala suficiente, isso vira matéria-prima para análise de risco.
E surge um ciclo extremamente poderoso:
MAIS CLIENTES
|
v
MAIS DADOS
|
v
MELHORES MODELOS
|
v
MELHOR RISCO
|
v
MAIS CRÉDITO
|
v
MAIS CLIENTES
Esse é um flywheel.
Uma roda que alimenta a si própria.
Para um programador COBOL isso pode parecer distante.
Não é.
Porque em algum ponto todos esses modelos precisam conversar com sistemas transacionais.
Pode existir uma IA sofisticadíssima decidindo:
LIMIT = 8500
Mas alguém precisa registrar isso.
Controlar.
Auditar.
Autorizar.
Persistir.
E eventualmente cobrar.
Nesse momento você encontra novamente:
CORE
Capítulo 12 — Pix mudou as regras do tabuleiro
Depois ocorreu outra transformação gigantesca.
Pix.
Antes, movimentar dinheiro entre bancos tinha mais fricção.
TED.
DOC.
Horários.
Tarifas.
Prazo.
O Pix reduziu dramaticamente isso.
De repente:
BANCO A
|
PIX
|
v
BANCO B
quase instantaneamente.
Isso teve uma consequência econômica importante:
reduziu o aprisionamento do cliente.
Se dinheiro circula facilmente, possuir conta em vários bancos fica muito menos complicado.
Você pode manter:
BANCO TRADICIONAL
+
FINTECH
+
CORRETORA
e movimentar recursos entre eles.
Para challengers como Nubank isso é excelente.
A infraestrutura nacional passa a reduzir parte da vantagem das redes tradicionais.
Easter egg nº 2
Para quem viveu TED e DOC:
Pix parece MOVE CORRESPONDING.
Só que alguém finalmente colocou:
SYNCHRONOUS
na operação.
Capítulo 13 — Open Finance e o fim do castelo fechado
Depois veio Open Finance.
Conceitualmente, a ideia é poderosa:
os dados financeiros pertencem ao cliente.
Com autorização, informações podem transitar entre instituições.
Isso reduz outro moat tradicional.
Antes:
BANCO
|
+-- possui histórico
+-- conhece cliente
+-- controla relacionamento
Agora potencialmente:
CLIENTE
|
+-- autoriza compartilhamento
Isso aumenta competição.
O banco deixa de ser simplesmente o proprietário da informação.
Vira guardião de dados cuja circulação pode ser autorizada.
É uma mudança filosófica enorme.
Capítulo 14 — Por que os gigantes não esmagaram o Nubank?
Chegamos à pergunta mais interessante.
Itaú tinha dinheiro.
Bradesco tinha dinheiro.
Santander tinha dinheiro.
Banco do Brasil tinha dinheiro.
Todos tinham equipes de TI gigantescas.
Então por que simplesmente não copiaram tudo?
Aqui aparece o famoso:
Innovator's Dilemma.
Imagine que você ganha bilhões com:
ANUIDADE
TARIFA
PACOTE
SERVIÇOS
Aparece alguém dizendo:
— Precisamos eliminar tarifas.
Seu diretor financeiro pergunta:
— Quanto isso custa?
— Alguns bilhões.
— E quanto ganhamos?
— Talvez no futuro evitemos perder clientes.
Excelente reunião.
😂
Para uma startup:
receita existente = 0
Ela pode destruir um modelo econômico porque não tem receita antiga para proteger.
Para uma empresa incumbente:
CANIBALIZAR PRODUTO
é uma decisão dolorosa.
Esse é um dos motivos pelos quais empresas pequenas conseguem ameaçar gigantes.
Elas não possuem passado.
O passado é ativo.
Mas também pode ser peso.
Capítulo 15 — Legado tecnológico versus legado organizacional
Outro ponto importantíssimo.
Quando ouvimos:
LEGADO
pensamos:
COBOL
MAINFRAME
Mas existe legado muito mais perigoso:
LEGADO ORGANIZACIONAL
Exemplo:
— Por que precisamos dessa aprovação?
— Porque sempre foi assim.
— Quem aprovava?
— Um departamento extinto em 2004.
— Então por que ainda aprovamos?
— Não sei.
Esse tipo de coisa existe em toda grande organização.
Veja:
legacy code
legacy process
legacy policy
legacy incentive
legacy hierarchy
legacy culture
Às vezes reescrever o sistema é fácil.
Difícil é reescrever a empresa.
Capítulo 16 — O Nubank mudou os concorrentes
Uma das maiores vitórias de uma inovação acontece quando os concorrentes passam a copiá-la.
Hoje bancos tradicionais oferecem:
app excelente
Pix
cartão virtual
controle digital
conta sem tarifa
atendimento digital
investimentos no app
biometria
notificações
Isso significa que o Nubank venceu todos?
Não.
Significa algo mais interessante:
ele alterou a referência do consumidor.
Antes o cliente comparava:
BANCO A vs BANCO B
Depois passou a comparar:
EXPERIÊNCIA DIGITAL A vs EXPERIÊNCIA DIGITAL B
Isso força todo mundo a melhorar.
Capítulo 17 — Os gigantes continuam gigantes
Não caia na narrativa simplista:
Fintech matou bancos tradicionais.
Não matou.
Os grandes bancos continuam tendo vantagens absurdas.
Corporate banking.
Agronegócio.
Financiamento imobiliário.
Crédito estruturado.
Câmbio.
Tesouraria.
Derivativos.
Seguros.
Gestão patrimonial.
Redes empresariais.
Capital.
Conhecimento regulatório.
Relacionamentos institucionais.
Infraestrutura.
Décadas de dados.
O mundo bancário é muito maior do que cartão de crédito.
Então a disputa não é:
NUBANK VS BANCO
É:
QUAL PARTE DA CADEIA FINANCEIRA
CADA UM CONSEGUE DOMINAR?
Muito mais interessante.
Capítulo 18 — O que um COBOLzeiro iniciante aprende com tudo isso?
Agora chegamos ao café.
Você começou COBOL e pensa:
— O que Nubank tem a ver comigo?
Tudo.
Passo 1 — Aprenda o core
Antes de criticar sistema legado, entenda-o.
Estude:
COBOL
JCL
CICS
DB2
VSAM
IMS
MQ
RACF
Entenda por que cada coisa existe.
Passo 2 — Pense em jornada
Não veja apenas:
PROGRAM A
Veja:
CLIENTE
|
v
CANAL
|
v
API
|
v
MIDDLEWARE
|
v
COBOL
|
v
DB2
O programa faz parte de uma experiência maior.
Passo 3 — Pergunte onde está a fricção
O gargalo pode não ser CPU.
Pode ser processo.
Pode ser autorização.
Pode ser formulário.
Pode ser arquitetura.
Pode ser gente.
Passo 4 — Não confunda modernização com reescrita
Modernizar pode significar:
expor API
automatizar deploy
melhorar observabilidade
integrar cloud
introduzir DevOps
reduzir etapas manuais
sem apagar o COBOL.
Passo 5 — Aprenda economia
Programador financeiro precisa entender:
receita
custo
risco
fraude
crédito
capital
margem
inadimplência
Seu código existe para sustentar negócio.
Passo 6 — Aprenda dados
Banco moderno é cada vez mais:
transação
+
dados
+
modelo
+
automação
Passo 7 — Nunca subestime UX
Um backend perfeito escondido atrás de uma experiência horrível continua sendo um produto ruim.
Capítulo 19 — O pequeno PERFORM que virou império
Existe algo quase poético na história do Nubank.
Ele não começou tentando resolver:
TODO O SISTEMA FINANCEIRO
Começou resolvendo:
UM PROBLEMA
Cartão.
Sem anuidade.
No smartphone.
Depois executou algo parecido com:
PERFORM EXPAND-PRODUCT
UNTIL CUSTOMER-BASE = HUGE
Isso é uma lição de arquitetura e de carreira.
Quem começa COBOL às vezes tenta aprender tudo ao mesmo tempo:
COBOL
JCL
CICS
DB2
IMS
MQ
Assembler
Java
Python
Cloud
DevOps
AI
Calma.
Comece pelo cartão roxo.
Escolha seu primeiro problema.
Domine.
Depois expanda.
Capítulo 20 — O verdadeiro Lobo Roxo
No fim das contas, o Nubank não venceu simplesmente porque era digital.
Também não venceu porque bancos antigos eram incompetentes.
Muito menos porque COBOL estava ultrapassado.
Ele cresceu porque uma combinação rara aconteceu ao mesmo tempo:
SMARTPHONE
+
UX
+
BAIXA FRICÇÃO
+
MARCA
+
TIMING
+
DISTRIBUIÇÃO DIGITAL
+
DADOS
+
ESCALA
+
MUDANÇAS REGULATÓRIAS
O cartão roxo foi apenas a face visível.
Por trás dele existia uma tese poderosa:
a experiência bancária podia ser reconstruída colocando o cliente digital no centro.
E existe uma ironia deliciosa.
Os bancos tradicionais passaram décadas criando fortalezas tecnológicas incríveis.
Mainframes.
Redes.
Datacenters.
Sistemas de liquidação.
Processamento massivo.
Segurança.
Redundância.
O Nubank não precisou destruir a fortaleza.
Encontrou uma porta lateral.
Essa porta chamava-se:
EXPERIÊNCIA
Entrou por ali.
Depois que entrou, começou a construir sua própria fortaleza.
Epílogo — Wall Street encontra o CPD
Imagine novamente o salão.
Os grandes bancos continuam sentados.
Só que agora existe outra cadeira na mesa.
Roxa.
O veterano do mainframe olha para o jovem programador COBOL.
— Aprendeu alguma coisa?
O rapaz responde:
— Que startup mata legado?
O veterano dá um gole no café.
— Não.
— Que mainframe morreu?
— Também não.
— Então o quê?
Ele aponta para uma tela onde milhões de transações passam por segundo.
— Sistemas não perdem mercado porque são velhos.
Pausa.
— Perdem mercado quando deixam de resolver aquilo que o cliente considera importante.
O novato fica pensando.
Na tela aparece:
TRANSACTION APPROVED
O veterano sorri.
— E outra coisa.
— O quê?
— Nunca confunda uma interface simples com um sistema simples.
Atrás do botão roxo existe um mundo.
Crédito.
Fraude.
Liquidação.
Compliance.
Segurança.
Auditoria.
Dados.
Regulação.
Resiliência.
E, em algum lugar escondido do planeta financeiro, provavelmente um programa escrito décadas atrás ainda está fazendo alguma coisa importantíssima.
Talvez seja COBOL.
Talvez ninguém saiba quem escreveu.
Talvez exista um comentário:
* DO NOT CHANGE THIS ROUTINE.
Sem nenhuma explicação.
O jovem pergunta:
— Posso apagar?
O veterano encara.
— Wall Street tem uma regra.
— Qual?
— Se você não sabe por que existe, não execute DELETE.
☕ Fim do café.
E lembre-se:
na próxima vez que alguém mostrar um aplicativo moderno e disser:
“Isso substituiu o banco antigo.”
Pergunte:
E ONDE LIQUIDA?
Normalmente é aí que a conversa começa a ficar realmente interessante.
