☕ Um Café no Bellacosa Mainframe
Gostou do conteúdo? Ajude a manter o café quente, o COBOL compilando e o mainframe acordado. 😄
☕ Pague um café ao Bellacosa

Translate

domingo, 9 de outubro de 2011

Present Bias: Doctor Who, COBOL e o Dia em que o Problema de Amanhã Perdeu para o Conforto de Hoje

Bellacosa Mainframe e o present bias


☕ Um Café no Bellacosa Mainframe

Present Bias: Doctor Who, COBOL e o Dia em que o Problema de Amanhã Perdeu para o Conforto de Hoje

Uma viagem pela TARDIS dos incidentes para entender por que preferimos economizar tempo, esforço e desconforto agora — mesmo quando sabemos que a conta futura será maior

08:11.

Segunda-feira.

Café recém-passado.

Produção estável.

Uma reunião rápida.

Tema:

ATUALIZAÇÃO DE ROTINA CRÍTICA

O analista explica:

— Precisamos revisar o programa de reconciliação.

O gerente pergunta:

— Está com problema?

— Ainda não.

— Então por que mexer?

— Porque estamos com pouca margem, a rotina depende de intervenção manual e o volume cresceu 30%.

Silêncio.

— Quanto tempo levaria?

— Talvez três dias de análise e testes.

O gerente olha para a lista de entregas.

— Não temos três dias agora.

— Podemos fazer no próximo ciclo.

— Ótimo.

Próximo ciclo.

Outra prioridade.

Depois:

auditoria.

Depois:

release.

Depois:

férias.

Depois:

fechamento.

Seis meses passam.

A rotina continua.

Todo dia alguém executa um pequeno workaround.

Cinco minutos.

Nada demais.

Até que:

03:21:44

RECONCILIATION FAILED

03:22.

Operador corrige manualmente.

03:29.

Produção normal.

Nada grave.

Então todos respiram.

— Depois corrigimos definitivamente.

Mais seis meses.

Agora o workaround leva vinte minutos.

Depois quarenta.

Depois precisa de duas pessoas.

Depois existe uma planilha.

Depois um script.

Depois uma instrução de oito páginas explicando como contornar o sistema que ainda “funciona”.

Até que numa madrugada:

02:41

RECONCILIATION FAILED
MANUAL PROCEDURE FAILED
BACKLOG: 1.870.000 RECORDS

A War Room abre.

Alguém pergunta:

— Como chegamos aqui?

VWORP.

VWORP.

VWORP.

A TARDIS materializa-se ao lado da impressora.

A porta abre.

O Doctor sai.

Olha para a timeline.

— Quando vocês perceberam que esse problema existia?

O gerente responde:

— Hoje.

Nosso jovem programador COBOL olha para a documentação.

— Na verdade...

Pausa.

— Há registros de mais de um ano.

Silêncio.

O Doctor sorri.

— Ah.

— O quê?

— Então o problema não era invisível.

Aponta para a lista de adiamentos.

— Só estava sempre perdendo para alguma coisa mais urgente.

Bem-vindo ao:



Present Bias

Ou:

Viés do Presente

A tendência de dar peso excessivo aos custos e benefícios imediatos e peso insuficiente às consequências futuras.

Em português operacional:

“Resolvo depois.”


🌀 Nossa TARDIS dos incidentes está ficando lotada

Até aqui conhecemos:

Swiss Cheese Model — várias barreiras podem falhar juntas.

Normalization of Deviance — desvios viram rotina.

Hindsight Bias — o passado parece óbvio depois.

Confirmation Bias — buscamos provas para aquilo que acreditamos.

Anchoring Bias — a primeira informação pesa demais.

Groupthink — grupos convergem cedo demais.

Authority Gradient — hierarquia silencia sinais importantes.

Plan Continuation Bias — continuamos porque já começamos.

Alarm Fatigue — alertas demais viram ruído.

Automation Bias — confiamos demais na máquina.

Drift Into Failure — pequenas adaptações empurram sistemas para a borda.

Diffusion of Responsibility — todo mundo vê e ninguém assume.

Normalcy Bias — esperamos que tudo volte ao normal.

Survivorship Bias — estudamos apenas quem sobreviveu.

Base Rate Neglect — ignoramos frequências reais.

Availability Heuristic — o que lembramos facilmente parece mais provável.

Outcome Bias — confundimos resultado bom com decisão boa.

Overconfidence Bias — acreditamos que sabemos mais do que sabemos.

Planning Fallacy — subestimamos tempo e complexidade.

Sunk Cost Fallacy — gastos passados nos prendem ao futuro.

Status Quo Bias — preferimos o estado atual porque já existe.

Agora encontramos um combustível poderoso para vários desses vieses:

o conforto imediato.


🧠 O que é Present Bias?

Imagine duas opções.

Opção A

Resolver hoje.

Custo:

dor;

tempo;

teste;

trabalho;

reunião;

risco de mudança.

Opção B

Não resolver hoje.

Custo imediato:

quase zero.

Consequência futura:

possivelmente maior.

Nosso cérebro tende a dar peso desproporcional ao que acontece agora.

Então:

CUSTO HOJE = MUITO VISÍVEL

CUSTO FUTURO = ABSTRATO

Resultado:

“Depois fazemos.”

O problema?

O futuro eventualmente se transforma em presente.

E normalmente chega acompanhado de juros.


☕ Bellacosa Mainframe: o TODO de dez anos

Todo programador conhece:

      * TODO - CORRIGIR DEPOIS

O comentário é criado em 2016.

Em 2026:

      * TODO - CORRIGIR DEPOIS

O “depois” demonstrou impressionante resiliência.

Por quê?

Porque corrigir possui custo imediato.

Deixar como está possui custo futuro.

Então o futuro perde.


🧠 Temporal Discounting

Present Bias está relacionado a uma ideia chamada desconto temporal.

Simplificando:

tendemos a valorizar mais algo disponível agora do que algo equivalente no futuro.

R$100 hoje parece mais valioso que R$100 daqui a um ano.

Isso pode ser racional em algum grau.

O problema aparece quando descontamos o futuro de maneira exagerada.

Em TI:

“Economizamos duas horas hoje.”

Excelente.

Mas criamos:

20 horas mensais de operação manual.

A economia imediata parece vitória.

O custo futuro vai ficando invisível.


📊 A matemática do workaround

Imagine:

corrigir definitivamente:

16 horas de trabalho

Workaround manual:

20 minutos/dia

Parece barato.

Mas em 1 ano:

20 min × 250 dias
=
5.000 minutos
=
83 horas

Você evitou 16 horas.

Criou 83.

E continua aumentando.

Present Bias faz o primeiro número parecer grande.

E o segundo desaparecer porque está dividido no tempo.


🧠 Microcustos escondem macroproblemas

Cinco minutos aqui.

Dez ali.

Um restart.

Uma intervenção.

Uma planilha.

Separadamente:

pequenos.

Acumulados:

enormes.

Esse é um ponto central.

O futuro frequentemente cobra em parcelas pequenas antes de mandar a fatura grande.


👻 Easter Egg nº 1 — “Resolveremos amanhã”

Imagine Doctor Who.

Uma rachadura temporal aparece.

Companion:

— Devemos fechar isso?

Doctor:

— Sim.

— Agora?

— Temos chá.

— Então amanhã?

Corta para:

três universos colidindo.

Present Bias aplicado à cosmologia.


🌀 Present Bias + Status Quo Bias

Nosso episódio anterior encaixa perfeitamente.

Status Quo Bias diz:

“Mudar parece arriscado.”

Present Bias acrescenta:

“E dá trabalho agora.”

Resultado:

não fazemos nada.

O sistema atual ganha duas vantagens:

familiaridade;

conforto imediato.


💰 Present Bias + Sunk Cost

Já gastamos muito no sistema atual.

Mudar custa hoje.

Benefício aparece depois.

Então:

“Vamos manter.”

Sunk Cost protege o passado.

Present Bias protege o presente.

O futuro fica sem advogado.


🌀 Drift Into Failure adora isso

Cada melhoria preventiva é adiada.

Margem cai.

Workarounds aumentam.

Capacidade diminui.

Nada explode hoje.

Então:

“Ainda dá.”

Centímetro por centímetro:

Drift Into Failure.

Present Bias é uma das forças que empurra.


🧠 Normalization of Deviance

Workaround temporário.

Hoje:

mais fácil usar.

Amanhã:

também.

Depois:

normal.

O desvio é mantido porque corrigir exige custo imediato.

Normalization of Deviance transforma Present Bias em procedimento.


🔔 Alarm Fatigue

Alerta ruidoso.

Ajustar monitoramento leva trabalho.

Mais fácil:

silenciar.

Resolve o incômodo hoje.

Mas talvez elimine capacidade de detectar problema amanhã.

Present Bias:

conforto imediato.

Risco futuro.


🔐 Segurança é terreno fértil

Patch.

Agora:

precisa testar.

Pode causar indisponibilidade.

Tem mudança.

Tem CAB.

Adiar:

produção tranquila hoje.

Mas vulnerabilidade fica aberta.

Present Bias pode empurrar patch indefinidamente.


🧠 “Não aconteceu nada ainda”

Essa frase mistura:

Normalcy Bias;

Outcome Bias;

Present Bias.

“Não precisamos fazer hoje porque nada aconteceu.”

Mas controles preventivos existem exatamente para antes.

Depois do incidente:

já não são prevenção.

São recuperação.


🧯 Manutenção preventiva

Pense num carro.

Trocar óleo:

custo agora.

Não trocar:

economia agora.

Motor quebrado:

custo depois.

TI funciona igual.

Só que o motor pode processar milhões de transações bancárias.


💾 Storage

Dataset:

80%.

85%.

90%.

Planejar expansão:

trabalho.

Hoje ainda cabe.

Então:

“Depois.”

95%.

98%.

03:00.

Incidente.

Present Bias transforma capacity planning em firefighting.


📈 Capacity Planning é exercício de respeito pelo futuro

Você compra capacidade antes de precisar.

Isso parece desperdício.

Até precisar.

Margin é recurso que existe precisamente para eventos futuros.

Present Bias gosta de consumir margem porque seu benefício não aparece imediatamente.


☕ “CPU ociosa é dinheiro parado”

Talvez.

Mas se eliminar toda folga:

qualquer pico vira crise.

Eficiência absoluta e resiliência raramente são a mesma coisa.


🧠 Slack organizacional

Slack aqui não é a ferramenta de chat.

É folga.

Tempo.

Capacidade.

Pessoas.

Um sistema sem folga parece eficiente.

Mas pode ser frágil.

Present Bias incentiva cortar a folga porque economia aparece hoje.

A fragilidade aparece amanhã.


🧀 Swiss Cheese + Present Bias

Barreira 1:

backup.

Custo hoje.

Barreira 2:

teste.

Custo hoje.

Barreira 3:

redundância.

Custo hoje.

Barreira 4:

treinamento.

Custo hoje.

Incidente:

talvez nunca.

Então alguém pergunta:

“Por que gastamos nisso?”

Present Bias começa a furar o queijo.


🧠 Prevention Paradox volta

Quando prevenção funciona:

nada acontece.

E justamente por nada acontecer, ela pode parecer desnecessária.

Resultado:

cortamos.

Até descobrir por que existia.

Present Bias torna prevenção politicamente difícil porque benefício é invisível e futuro.


👥 Gestão e metas trimestrais

Aqui o problema sai da psicologia individual e vira desenho organizacional.

Imagine gerente avaliado por:

custo deste trimestre.

Investimento em prevenção reduz resultado imediato.

Incidente talvez aconteça no ano seguinte.

Que incentivo existe?

Talvez racionalmente ele adie.

Agora Present Bias foi institucionalizado.


🧠 Short-termism

Esse comportamento pode aparecer como short-termism:

foco excessivo em resultados de curto prazo às custas de saúde futura.

Em tecnologia:

reduzir equipe;

adiar manutenção;

cortar testes;

empurrar dívida técnica.

O trimestre melhora.

Sistema piora.


💸 Dívida técnica é crédito no banco do futuro

Analogia perfeita.

Atalho hoje:

ganha tempo.

Mas paga:

juros.

Cada mudança futura custa mais.

Technical debt não é automaticamente ruim.

Às vezes tomar dívida é racional.

Mas precisa ser consciente.


☕ Bellacosa Bank of Technical Debt

Contrato:

PRINCIPAL:
8 horas economizadas hoje

JUROS:
2 horas extras em cada manutenção futura

Quantas manutenções?

Se vinte:

péssimo negócio.


🧠 Dívida sem plano vira presente permanente

Dívida técnica pode ser aceitável se:

temporária;

documentada;

com owner;

prazo;

plano de pagamento.

Sem isso:

vira Status Quo.


💻 COBOL iniciante: “faço hardcode agora”

Exemplo:

       IF WS-CODE = '8472'
           MOVE 'Y' TO WS-VALID
       END-IF.

Negócio:

— Precisamos hoje.

Hardcode resolve.

Pode ser perfeitamente justificável.

Problema:

ninguém cria tarefa para parametrizar.

Cinco anos depois:

       IF WS-CODE = '8472'
          OR WS-CODE = '9221'
          OR WS-CODE = '1034'
          OR WS-CODE = '1148'
          OR ...

Present Bias construiu arquitetura.

Uma urgência de cada vez.


🧠 Tactical versus Strategic

Solução tática:

resolve agora.

Solução estratégica:

melhora futuro.

Ambas podem ser necessárias.

O erro é deixar solução tática virar estratégica por abandono.


📋 Regra simples

Todo workaround deveria responder:

POR QUÊ?
OWNER?
DATA DE EXPIRAÇÃO?
CORREÇÃO DEFINITIVA?

Se não:

o temporário está tentando comprar residência permanente.


▶️ Plan Continuation Bias

Projeto atrasado.

Parar agora é doloroso.

Continuar é mais confortável no instante.

Present Bias pode reforçar Plan Continuation.

Benefício imediato:

evitar decisão difícil.

Custo futuro:

mais investimento.


🧠 Procrastinação é prima

Procrastinação e Present Bias possuem conexão intuitiva.

Escrever documentação:

dor agora.

Benefício depois.

Então:

depois.

Fazer teste:

custo agora.

Bug evitado:

futuro e abstrato.

Depois.

Treinar sucessor:

tempo agora.

Risco de conhecimento:

futuro.

Depois.


👨‍💻 Documentação

Um dos maiores exemplos.

Desenvolvedor pensa:

“Lembro perfeitamente.”

Hoje.

Daqui a dois anos:

não.

Ou nem estará mais na equipe.

Documentar tem custo presente e benefício futuro.

Logo:

é vítima natural.


🧠 Bus Factor + Present Bias

Treinar alguém:

leva tempo hoje.

Mais fácil:

Carlos resolve.

Amanhã Carlos continua.

Até um dia não.

De repente a economia passada aparece como risco.


👥 Cross-training

Duplicar conhecimento parece ineficiente.

Duas pessoas aprendendo mesma coisa.

Mas é redundância.

Present Bias enxerga:

custo duplicado hoje.

Resiliência aparece só depois.


🪜 Authority Gradient e prioridades

Júnior:

— Deveríamos corrigir isso.

Gerente:

— Não é prioridade.

Tudo bem.

Mas pergunte:

“O que precisaria acontecer para virar prioridade?”

Sem critério:

“não prioritário” pode significar:

nunca.


🎯 Pergunta Bellacosa nº 1

Quando alguém disser:

“Fazemos depois.”

Pergunte:

“Quando exatamente é depois?”

Se não tem data:

talvez signifique nunca.


🎯 Pergunta Bellacosa nº 2

Outra:

“Quanto economizamos hoje e quanto isso custa ao longo de um ano?”

Transforme futuro em número presente.


🎯 Pergunta Bellacosa nº 3

Outra:

“Que risco estamos transferindo para a equipe futura?”

Excelente para arquitetura.


🎯 Pergunta Bellacosa nº 4

E:

“Se o problema explodir amanhã, vamos desejar ter gasto essas duas horas hoje?”


🧪 Como combater Present Bias

Passo 1 — Traga o futuro para o presente

Quantifique.


Passo 2 — Calcule custo acumulado

Não só custo unitário.


Passo 3 — Dê owner aos débitos

Nada de TODO órfão.


Passo 4 — Coloque data de expiração

Workaround precisa vencer.


Passo 5 — Reserve capacidade para manutenção

Se manutenção compete sempre com features, sempre perde.


Passo 6 — Automatize o futuro bom

Backup.

Testes.

Patches.

Monitoramento.


Passo 7 — Use precommitment

Defina antes quando corrigir.


Passo 8 — Crie thresholds

Quando risco futuro vira ação presente?


Passo 9 — Inclua custo de oportunidade

O que o workaround está consumindo?


Passo 10 — Meça dívida acumulada

Se não mede, some.


📊 Future Cost Dashboard

Imagine:

MANUAL WORKAROUNDS
143/mês

TEMPO:
36h/mês

CUSTO:
R$ X/ano

INCIDENT RISK:
crescendo

Agora “depois” deixa de ser abstrato.


🧠 Hyperbolic Discounting

Existe uma forma interessante de pensar nesse viés.

A distância temporal muda percepção de valor de maneira não linear.

Exemplo:

Hoje:

fazer duas horas de documentação dói.

Daqui a seis meses:

você adoraria ter aquela documentação.

Mas seis meses atrás:

não parecia urgente.

Essa inconsistência temporal é uma característica importante de como avaliamos presente e futuro.


☕ O “eu de amanhã” é sempre mais organizado

Hoje:

— Amanhã documento.

Amanhã:

— Amanhã documento.

Surpreendentemente, o profissional de amanhã possui agenda infinita.

Precisamos parar de terceirizar trabalho para essa criatura mitológica.


👻 Easter Egg nº 2 — o funcionário do futuro

Doctor:

— Quem vai corrigir isso depois?

Gerente:

— Nossa equipe futura.

Doctor:

— Quem exatamente?

Silêncio.

— Ah. Mais um funcionário imaginário.

Primo do famoso “alguém” da Diffusion of Responsibility.


🧠 Present Bias + Diffusion of Responsibility

“Depois alguém resolve.”

Aqui temos:

tempo indefinido;

pessoa indefinida.

Perfeito.

O problema alcançou invisibilidade máxima.


🗓️ Owner + Date

Uma tarefa real:

ACTION:
Eliminar workaround X

OWNER:
Maria

DUE:
30/09

SUCCESS:
zero intervenção manual

Agora o futuro ganhou endereço.


🔄 Continuous Improvement

Melhoria contínua existe justamente porque problemas pequenos precisam ser tratados antes de virarem grandes.

Um percentual fixo da capacidade pode ser reservado para:

dívida;

automação;

observabilidade;

documentação.

Não existe número universal.

O princípio é:

o futuro precisa ter orçamento.


🧠 Se só financiamos urgência, produzimos mais urgência

Essa frase merece destaque.

Equipe sempre ocupada apagando incêndio.

Nunca melhora.

Porque melhoria não é urgente.

Então incêndios continuam.

Agora temos um ciclo:

INCIDENTE
↓
CORREÇÃO RÁPIDA
↓
SEM TEMPO PARA CORREÇÃO ESTRUTURAL
↓
NOVO INCIDENTE
↓
CORREÇÃO RÁPIDA

Present Bias vira modelo operacional.


🔥 Firefighting Culture

Algumas organizações até valorizam heroísmo.

Pessoa salva produção.

Recebe elogio.

Quem automatizou e evitou o incidente?

Ninguém percebe.

Outcome Bias + Present Bias.

Recuperação imediata é visível.

Prevenção futura, não.


🧠 Incentivo à prevenção

Mude reconhecimento.

Celebre:

alerta eliminado;

runbook melhorado;

reprocessamento removido;

dívida paga;

near miss evitado.

Isso ajuda a equilibrar presente e futuro.


🔐 Patch Tuesday e depois

Patch está disponível.

Negócio:

— Não podemos parar agora.

Semana seguinte:

— Ainda não.

Mês seguinte:

— Estamos em freeze.

Outro:

— Agora fechamento.

Esse calendário pode existir.

Mas vulnerabilidade não respeita agenda.

Precisamos definir:

risco;

prazo máximo;

compensating controls.


🧠 Risk Acceptance com validade

Se adiar:

registre:

RISCO:
CVE X

ACEITO POR:
Y

ATÉ:
DATA Z

COMPENSATING CONTROL:
W

FIX:
JANELA N

Isso transforma Present Bias em decisão governada.


☁️ Cloud cost optimization

Outro exemplo.

Instância superdimensionada.

Custa R$ 10 mil/mês extra.

Corrigir leva um dia.

Mas:

“estamos sem tempo.”

Um ano:

R$ 120 mil.

Present Bias também queima dinheiro.


🧠 Pequenos custos recorrentes importam

Sistemas grandes escondem milhares de microdesperdícios.

Cada um parece pequeno.

Acumulado:

milhões.

FinOps, capacity planning e observabilidade ajudam a transformar futuro em dado.


🏦 Present Bias em finanças e legado

Um banco pode preferir adiar modernização porque o sistema ainda funciona.

Talvez correto.

Mas se todo investimento preventivo perde para metas trimestrais:

mais cedo ou mais tarde o futuro cobra.

A questão é construir equilíbrio entre:

estabilidade atual;

capacidade futura.


🧠 Modernização sem hype

Present Bias não significa:

“faça tudo agora.”

Isso seria absurdo.

Recursos são finitos.

Precisamos priorizar.

O ponto é:

não tratar benefício futuro como zero só porque não chega esta semana.


⚖️ Discount Rate explícita

Na prática, organizações podem comparar:

custo agora;

benefício anual;

risco evitado.

Mesmo sem matemática sofisticada.

Exemplo:

CORREÇÃO:
40h

WORKAROUND ATUAL:
10h/mês

PAYBACK:
4 meses

Agora decisão fica concreta.


📈 Payback técnico

Essa ideia é poderosa.

Uma automação custa:

80h.

Economiza:

20h/mês.

Payback:

4 meses.

Depois disso:

ganho.

É mais difícil adiar indefinidamente quando isso está visível.


💻 Refactoring economics

Refatorar não é automaticamente bom.

Pergunte:

  • quanto custa?

  • quanto reduz manutenção?

  • quantas mudanças futuras?

  • qual risco?

Talvez não valha.

Mas calcule.

Não simplesmente:

“não temos tempo.”


🧠 Opportunity Cost novamente

Se gastamos toda capacidade em feature urgente:

não investimos em:

testes;

segurança;

automação.

Resultado futuro:

mais lentidão.

A empresa precisa tratar capacidade de engenharia como capital.


🎯 Pergunta Bellacosa nº 5

“Quanto da nossa semana existe para que a próxima semana seja melhor?”

Se resposta:

zero,

talvez tenhamos um problema estrutural.


📋 Checklist anti-Present Bias

[ ] Qual benefício imediato estamos escolhendo?

[ ] Qual custo futuro estamos aceitando?

[ ] Esse custo futuro está quantificado?

[ ] Quantas vezes esse workaround acontece?

[ ] Qual o custo anual acumulado?

[ ] Existe owner para a correção?

[ ] Existe data?

[ ] O “temporário” possui expiração?

[ ] O risco cresce com o tempo?

[ ] Estamos usando pessoas como buffer?

[ ] Estamos adiando porque é racional ou porque é desconfortável?

[ ] A decisão futura terá menos margem que hoje?

[ ] Existe payback claro para corrigir agora?

[ ] Se não fizermos nada por 12 meses, como estaremos?

🧠 Future Self Test

Pergunte:

“O que a equipe de daqui a um ano pensará desta decisão?”

Não é magia.

É perspectiva temporal.

Ajuda a quebrar fascínio pelo presente.


🧪 Pre-mortem temporal

Imagine:

“Daqui a um ano tivemos um incidente grave causado por esse problema.”

Pergunte:

“O que deixamos de fazer hoje?”

Isso força o futuro a entrar na reunião.


🌀 Status Quo + Present + Drift

Temos uma combinação extraordinária:

Status Quo:

não muda.

Present Bias:

não agora.

Drift:

enquanto isso, margem cai.

Essa tríade explica muitos sistemas que permanecem “estáveis” até o dia em que descobrimos que estabilidade era apenas ausência de perturbação suficiente.


🧠 Planning Fallacy também entra

— Corrigimos depois.

Quanto leva?

— Um dia.

Seis meses depois descobrem:

agora leva três semanas.

Por quê?

Complexidade cresceu.

Present Bias adiou.

Planning Fallacy subestimou.

O futuro ficou mais caro.


💰 Compound Interest da dívida técnica

Dívida pode acumular juros compostos.

Mais atalhos dependem de atalhos anteriores.

Correção fica exponencialmente mais difícil.

Isso é como juros:

tempo aumenta custo.


🧠 “Depois” não é neutro

Esperar pode:

aumentar volume;

aumentar complexidade;

reduzir skills;

perder documentação;

aumentar dependência.

Logo:

adiar não significa manter custo igual.

Pode multiplicá-lo.


👨‍💻 Dica para o COBOL iniciante

Se precisa fazer workaround:

faça.

Produção importa.

Mas escreva:

ticket;

owner;

razão;

expiração;

plano de remoção.

O problema não é improvisar numa emergência.

O problema é esquecer que improvisou.


☕ Regra Bellacosa do esparadrapo

Esparadrapo salva.

Mas se o paciente aparece cinco anos depois ainda coberto de esparadrapo:

talvez precisemos de cirurgia.

Workaround é esparadrapo.

Use.

Depois trate.


👻 Easter Egg nº 3 — Sonic Screwdriver Tape

Doctor:

— Colei provisoriamente.

Companion:

— Quanto dura?

Doctor:

— Até resolvermos de verdade.

Corta para:

três temporadas depois.

Até Time Lords precisam de backlog.


🧠 Incident follow-up

Após incidente:

hotfix.

Produção normal.

É aí que Present Bias aparece.

A pressão acabou.

Todos voltam às prioridades.

Root fix morre.

Então incident management deve incluir:

follow-up action;

owner;

deadline.


🔁 Post-Incident Improvement

Um incidente só gera aprendizado se ações realmente forem implementadas.

Senão:

post-mortem vira literatura.

Interessante.

Bem diagramada.

Inútil.


📊 Track closure quality

Não apenas:

action closed.

Pergunte:

risco foi realmente reduzido?

Porque também podemos ter Present Bias no fechamento:

marcar ticket como concluído com solução superficial.


🧠 Goodhart volta ao horizonte

Se KPI é:

“ações fechadas”,

pessoas fecham ações.

Não necessariamente corrigem sistema.

Métrica precisa refletir resultado de segurança.


🧬 Regeneração organizacional

Como regenerar uma organização dominada pelo presente?

Ela passa a:

quantificar custos recorrentes;

reservar capacidade para manutenção;

criar owners;

usar datas de expiração;

fazer business cases de automação;

valorizar prevenção;

medir dívida;

revisar workarounds;

criar stage gates;

e olhar 12, 24, 36 meses.

Principalmente:

transforma o futuro de abstração em item de backlog com nome, data e custo.


📓 Diário do Doctor

Se guardar apenas algumas ideias desta viagem, guarde estas:

Present Bias é a tendência de dar peso excessivo ao benefício e ao custo imediato e pouco peso às consequências futuras.

“Depois” precisa de data.

Workarounds pequenos podem acumular enormes custos.

Dívida técnica é benefício presente comprado com custo futuro.

Status Quo Bias e Present Bias reforçam um ao outro.

Drift Into Failure cresce quando manutenção preventiva é sempre adiada.

Prevenção parece cara porque seu benefício é invisível.

Capacidade para manutenção é investimento em resiliência.

Owner, prazo e expiração impedem que temporários virem permanentes.

O custo de não agir também precisa ser calculado.

E principalmente:

Toda vez que economizamos uma hora hoje criando dez horas para amanhã, não economizamos tempo — apenas fizemos um empréstimo com juros.


🕰️ De volta à reunião das 08:11

A rotina ainda tem:

143 INTERVENÇÕES/MÊS

O gerente diz:

— Não temos três dias agora.

Nosso programador abre a calculadora.

Cada intervenção:

15 minutos.

143 × 15
=
2.145 minutos
=
35h45 por mês

Mostra.

— Não temos três dias para corrigir.

Pausa.

— Então gastamos quase uma semana todo mês mantendo o problema.

Silêncio.

O Doctor sorri.

— Ah.

O gerente pergunta:

— Quanto tempo para payback?

— Menos de dois meses.

A decisão muda.

Equipe reserva três dias.

Corrige.

Automatiza.

Três meses depois:

INTERVENÇÕES/MÊS:
7

O gerente olha.

— Por que não fizemos isso antes?

Nosso programador sorri.

— Porque três dias atrás pareciam mais caros do que quarenta horas espalhadas pelo futuro.

Boa resposta.


🥚 Easter Egg final

No dia seguinte aparece:

BELLACOSA.BIAS(PRESENT)

Dentro:

       IF BENEFIT = 'NOW'
           PERFORM CALCULATE-FUTURE-COST
       END-IF.

       IF FIX = 'LATER'
           PERFORM REQUIRE-DATE
       END-IF.

       IF WORKAROUND = 'TEMPORARY'
           PERFORM SET-EXPIRATION
       END-IF.

Comentário:

* TOMORROW IS JUST TODAY
* WITH INTEREST.

Outro:

* TEMPORARY WITHOUT A DATE
* IS JUST PERMANENT IN DENIAL.

E naturalmente:

* BAD WOLF SAID "LATER".

Nosso jovem fecha o membro.

Pouco depois recebe um pedido:

— Podemos deixar essa validação para próxima sprint?

Ele pergunta:

— Podemos.

— Ótimo.

— Só preciso de três coisas.

— Quais?

— Owner, data e custo de esperar.

Silêncio.

— Tudo isso?

— Sim.

— Parece burocracia.

Ele olha para o velho workaround que acabaram de eliminar.

— Não.

Pausa.

— Burocracia é preencher papel sem propósito.

— E isso?

— Isso é impedir que “depois” vire uma arquitetura.

Em algum lugar:

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro permanece:

A urgência de hoje sempre fala mais alto. A engenharia madura é garantir que o futuro também tenha voz.

☕🌀

Next stop: Optimism Bias — quando reconhecemos que incidentes, atrasos e falhas acontecem com os outros, mas continuamos acreditando que conosco “provavelmente vai dar tudo certo”.

☕ Gostou deste café?
Siga o Bellacosa Mainframe e acompanhe os próximos artigos.
SEGUIR O BLOG

Sem comentários:

Enviar um comentário

De Fã para Fã. Conteúdo não oficial produzido como homenagem, comentário, análise ou paródia. Personagens, marcas e obras eventualmente mencionados pertencem aos seus respectivos titulares.
Vagner Renato Bellacosa, IBM Champion e especialista em IBM Mainframe
IBM Z17 SYSTEM ONLINE
Sobre o autor

Vagner Renato Bellacosa

IBM Champion 2026 • Especialista em IBM Mainframe

Vagner Renato Bellacosa trabalha com IBM Mainframe desde 1988 , é IBM Champion e especialista em COBOL, CICS, Db2, z/OS e IBM Z. Compartilha experiências profissionais, conhecimento técnico, história da computação e práticas do universo mainframe para aproximar novas gerações das tecnologias que sustentam empresas, bancos e governos ao redor do mundo.

IBM Champion IBM Z COBOL CICS Db2 z/OS Mainframe desde 1988
GitHub LinkedIn
Inicializando conteúdo...