☕ 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

quinta-feira, 15 de maio de 2014

Confirmation Bias: Doctor Who, COBOL e o Dia em que a War Room Encontrou Provas Demais para a Hipótese Errada

 

Bellacosa Mainframe e o confirmation bias

☕ Um Café no Bellacosa Mainframe

Confirmation Bias: Doctor Who, COBOL e o Dia em que a War Room Encontrou Provas Demais para a Hipótese Errada

Uma viagem pela TARDIS dos incidentes para entender por que nosso cérebro adora encontrar evidências que confirmem aquilo em que já acreditamos — e por que essa habilidade, tão útil para construir narrativas coerentes, pode ser absolutamente desastrosa quando estamos tentando descobrir o que realmente aconteceu

02:47.

War Room.

Na parede:

INCIDENTE P1

APLICAÇÃO:
PAYMENTS-X

SINTOMA:
LATÊNCIA INTERMITENTE

INÍCIO:
02:21

STATUS:
INVESTIGANDO

Primeiro comentário da madrugada:

— Isso está com cara de Db2.

Nosso jovem programador COBOL já aprendeu alguma coisa nas últimas noites.

Ele olha para a frase.

Não para o Db2.

Para a frase.

Porque sabe:

a primeira hipótese pode virar âncora.

Anchoring Bias.

Mas agora acontece algo novo.

O DBA abre o monitor.

— Lock.

Gerente:

— Aí.

Outro analista:

— Tem SQL acima da média.

Gerente:

— Mais uma.

Operação:

— Buffer pool também subiu.

Gerente:

— Está ficando claro.

Nosso jovem pergunta:

— E os timeouts externos?

Silêncio.

— Começaram antes do lock.

Resposta:

— Talvez sejam consequência.

Ele continua:

— Algumas chamadas que não usam Db2 ficaram lentas.

— Pode ser coincidência.

Interessante.

Lock:

causa.

Timeout:

consequência.

SQL:

prova.

API:

coincidência.

CPU Db2:

importante.

Network latency:

ruído.

Todos os dados existem.

Ninguém está:

inventando.

Mas as evidências estão recebendo:

pesos diferentes dependendo da direção para a qual apontam.

VWORP.

VWORP.

VWORP.

A TARDIS surge atrás do quadro.

Doctor sai.

Olha para a lista:

EVIDÊNCIAS A FAVOR DE DB2

✔ LOCKS
✔ SQL ELAPSED
✔ BUFFERPOOL
✔ CPU

Depois pergunta:

— Onde estão as evidências contra?

Gerente:

— Contra?

— Sim.

— Nós estamos investigando Db2.

Doctor:

— Percebi.

— Então por que procuraríamos evidência contra?

Doctor sorri.

— Porque vocês disseram que estão investigando.

Pausa.

— Não que estão preparando a acusação.

Bem-vindo ao:



Confirmation Bias

ou:

Viés de Confirmação.


🧠 O que é Confirmation Bias?

Em linguagem simples:

é nossa tendência de procurar, perceber, interpretar e lembrar informações de maneira que favoreça aquilo em que já acreditamos.

Isso significa que o viés não atua:

num único ponto.

Ele pode atuar:

quando escolhemos onde procurar;

quando decidimos quais dados são importantes;

quando interpretamos dados ambíguos;

quando lembramos de incidentes anteriores;

quando contamos a história depois.

Ou seja:

não é apenas:

“ver só o que queremos ver.”

É mais amplo:

organizar a própria investigação de maneira que aumente a chance de encontrar aquilo que esperamos encontrar.


☕ Definição Bellacosa

Confirmation Bias é quando o investigador contrata o próprio cérebro como advogado da hipótese e depois se surpreende quando o julgamento termina em condenação.


💻 COBOL cognitivo

Imagine este maravilhoso programa:

       IF EVIDENCE-SUPPORTS-HYPOTHESIS = 'Y'
           ADD 1 TO CONFIDENCE
       END-IF.

       IF EVIDENCE-CONTRADICTS-HYPOTHESIS = 'Y'
           MOVE 'NOISE'
             TO EVIDENCE-STATUS
       END-IF.

Compila.

Provavelmente.

Mas epistemologicamente:

ABEND S0BIAS.

O correto seria algo mais parecido com:

       EVALUATE EVIDENCE-TYPE
           WHEN 'SUPPORT'
                ADD 1 TO SUPPORT-COUNT

           WHEN 'CONTRADICT'
                ADD 1 TO CONTRADICT-COUNT

           WHEN OTHER
                ADD 1 TO UNKNOWN-COUNT
       END-EVALUATE.

E depois:

pensar.


🧠 O cérebro não falsifica necessariamente os dados

Isso é importante.

Quando falamos em Confirmation Bias, algumas pessoas imaginam:

“Ah, então alguém está manipulando informação.”

Não necessariamente.

Pode ser um profissional:

honesto;

competente;

experiente.

O viés acontece:

antes.

Na atenção.

Na busca.

Na interpretação.


☕ Você não precisa apagar log

para cair no viés.

Basta:

abrir apenas o log que espera que tenha a resposta.


🧠 Exemplo clássico na War Room

Hipótese:

Db2.

Você procura:

Db2.

Encontra:

warning.

Agora:

confidence sobe.

Mas sistemas complexos têm:

milhares de warnings.

A pergunta certa não é:

“Existe warning?”

É:

“Esse warning é anormal, temporalmente relevante e causalmente consistente com o incidente?”

Isso muda:

tudo.


🎯 Pergunta Bellacosa nº 1

“Essa evidência seria interessante para mim se eu não tivesse essa hipótese?”

Excelente.


🧠 Baseline, o inimigo do drama

Imagine:

DB2 LOCKS:
25

Parece ruim?

Talvez.

Historical baseline:

NORMAL:
20–30

Então:

normal.

Agora outro:

API LATENCY:
NORMAL 150 ms
INCIDENT 2400 ms

Muito mais relevante.

Mas se nossa hipótese é:

Db2,

podemos passar:

vinte minutos

discutindo 25 locks

e três segundos:

na API.


☕ Um número grande não é automaticamente anormal

E um número pequeno não é automaticamente irrelevante.

Contexto.

Sempre.


🧠 Anchoring abre a porta

Lembra?

Primeiro alguém diz:

“Tem cara de Db2.”

Anchoring Bias.

Agora Confirmation Bias entra:

“Vamos procurar sinais de Db2.”

Uma relação quase:

pai e filho.


🌀 Pipeline cognitivo

PRIMEIRO PALPITE
      ↓
ANCHORING
      ↓
BUSCA SELETIVA
      ↓
CONFIRMATION BIAS
      ↓
MAIOR CONFIANÇA

Mas ainda não acabou.


🧠 Streetlight Effect ajuda a confirmar

Temos:

ótimos logs Db2.

Ótimo dashboard Db2.

DBA presente.

Então:

procuramos Db2.

Quanto mais procuramos:

mais encontramos.

Isso não significa:

Db2 mais culpado.

Significa:

Db2 mais observado.

Streetlight Effect.


☕ Se você apontar 20 lanternas para um componente

e nenhuma para outro,

adivinhe:

qual vai produzir mais evidência.


🧠 Search Satisfaction entra depois

Encontramos:

um lock interessante.

Pronto.

Achei!

Search Satisfaction.

Agora:

a busca perde força.


🧠 Premature Closure chega

Lock:

real.

Latency:

real.

Então:

“Db2 é root cause.”

Premature Closure.


🧠 Diagnosis Momentum termina o serviço

Ticket:

POSSIBLE DB2

vira:

DB2 ISSUE

Depois:

ROOT CAUSE DB2

Diagnosis Momentum.

Veja o arco:

ANCHOR
  ↓
CONFIRM
  ↓
FIND
  ↓
STOP
  ↓
CLOSE
  ↓
PROPAGATE

É praticamente:

pipeline CI/CD de erro cognitivo.


👻 Easter Egg nº 1 — Doctor e o Dalek Promotor

Dalek:

— DB2 IS GUILTY.

Doctor:

— Por quê?

— LOCK FOUND.

— Existe alguma evidência de API failure?

— YES.

— Então?

— IRRELEVANT.

— Por quê?

— IT DOES NOT SUPPORT DB2 THEORY.

Doctor:

— Você não é investigador.

Dalek:

— CORRECT.

— O que é?

— PROSECUTION.

Doctor:

— Finalmente honestidade.


🧠 Confirmation Bias não acontece apenas na busca

Ele atua em:

1. Busca

Procuramos:

o que confirma.

2. Atenção

Notamos:

o que confirma.

3. Interpretação

Ambiguidade vira:

suporte.

4. Memória

Lembramos:

de casos favoráveis.

5. Comunicação

Contamos:

história favorável.

Uma criatura:

multifuncional.


🧠 Memória seletiva

Alguém diz:

— Toda vez que Db2 sobe CPU, temos incidente.

Será?

Talvez ele lembre:

dos três incidentes.

Mas não dos:

200 dias

em que CPU subiu

e nada aconteceu.

Base Rate Neglect.

Confirmation Bias.


🎯 Pergunta Bellacosa nº 2

“Quantas vezes esse mesmo sinal apareceu sem o incidente?”

Uma pergunta brutalmente importante.


🧠 O normal que não lembramos

Incidentes:

memoráveis.

Operação saudável:

esquecível.

Então:

correlações parecem:

fortes.


☕ Ninguém abre War Room para:

“mais uma terça-feira onde tudo funcionou.”

Isso distorce memória.


🧠 Confirmation Bias e Availability Heuristic

Você se lembra:

do incidente Db2.

Porque:

dramático.

Disponível na memória.

Então:

essa hipótese surge rápido.

Depois:

Confirmation Bias procura provas.


🧠 Recency Bias

Se aconteceu:

ontem,

pior ainda.

“Deve ser de novo.”


🧠 Representativeness

“Tem o mesmo cheiro.”

Parecido:

não significa:

igual.


🎯 Pergunta Bellacosa nº 3

“Quais diferenças entre este caso e o caso anterior estamos deixando de considerar?”


🧠 A arte de procurar contra você mesmo

Esse talvez seja:

o principal antídoto.

Se hipótese:

Db2,

não pergunte apenas:

“Que evidência prova Db2?”

Pergunte:

“Que evidência provaria que Db2 NÃO é o gatilho?”

Essa mudança:

é enorme.


🧠 Falsification mindset

Imagine:

HYPOTHESIS:
DB2 causes payment latency.

Teste:

Clientes que não tocam Db2 também estão lentos?

Se sim:

problema.

Outro:

Latency begins before Db2 anomaly?

Se sim:

problema.

Outro:

Remove Db2 contention and latency remains?

Problema.


☕ Hipótese boa precisa:

correr risco de morrer.

Caso contrário:

é decoração.


🧠 House MD entra

Equipe:

— Achamos pneumonia.

House:

— O que contradiz?

— Nada.

— Procuraram?

— Não.

— Então vocês não têm “nada que contradiz”.

Pausa.

— Vocês têm “nada que procuramos para contradizer”.

Essa diferença é:

fantástica.


🎯 Pergunta Bellacosa nº 4

“Ausência de contradição ou ausência de busca por contradição?”


🧠 Confirmation Bias em debugging COBOL

Programa:

resultado incorreto.

Programador pensa:

“é o COMPUTE.”

Então abre:

COMPUTE WS-TOTAL =
        WS-PRICE * WS-QUANTITY.

Lê.

Relê.

Encontra:

arredondamento estranho.

Corrige.

Teste melhora.

Pronto?

Talvez não.

O campo:

WS-PRICE

já estava:

errado.

Então:

o problema no COMPUTE era:

real?

Talvez.

Mas talvez:

secundário.


🧠 Trace backwards

Pergunta senior:

“Onde aparece o primeiro valor errado?”

Não:

onde encontramos:

um cálculo suspeito.


☕ O primeiro lugar onde percebemos o erro

não é necessariamente:

o primeiro lugar onde ele existe.


🧠 Exemplo de lineage

INPUT
  OK
   ↓
COPYBOOK MAPPING
  WRONG
   ↓
MOVE
  WRONG
   ↓
COMPUTE
  WRONG
   ↓
REPORT
  WRONG

Se você ama a hipótese:

COMPUTE,

talvez fique:

no quarto andar.

Causa:

segundo.


🎯 Pergunta Bellacosa nº 5

“Estou investigando a origem do valor ou apenas o ponto onde ele finalmente ficou visível?”


🧠 Confirmation Bias e testes

Desenvolvedor escreve:

testes.

Se quer:

confirmar código,

faz:

happy path.

Tudo passa.

Excelente.

Mas:

boundary?

negative?

invalid?

concurrency?


☕ Testar só o que espera funcionar

é quase:

pedir elogio ao compilador.


🧠 Mutation Testing como filosofia anti-confirmação

Interessante.

Pergunta:

“Se o código estivesse errado, meus testes perceberiam?”

Isso é mais poderoso do que:

“meu código passa?”

Porque:

passar não garante:

qualidade.


🧠 Negative Testing

Ideal:

tente destruir.


🎯 Pergunta Bellacosa nº 6

“Qual teste eu escreveria se estivesse tentando provar que minha implementação está errada?”


🧠 Confirmation Bias em code review

Autor:

“simple change.”

Reviewer:

já ancorado.

Procura:

pequeno ajuste.

Talvez:

copybook global.

Danger.


☕ “Mudança simples”

é um dos comentários mais perigosos:

do software corporativo.


🧠 Neutral review

Better:

“change modifies X.”

Then:

review.

Avoid:

framing.


🧠 Confirmation Bias em RCA

Postmortem começa:

— O deploy causou.

Agora:

todo mundo procura:

deploy.

Mas talvez:

deploy coincidiu.

Post hoc.


🎯 Pergunta Bellacosa nº 7

“Estamos investigando o evento porque ocorreu antes ou porque demonstramos mecanismo causal?”


🧠 Timeline limpa

Uma ferramenta maravilhosa:

escreva:

02:51 API latency
02:52 retries
02:55 queue
03:01 DB2 lock

Sem:

“cause”.

Sem:

“because”.

Só fatos.

Depois:

analise.

Isso reduz:

narrativa prematura.


☕ Timeline sem opinião

é:

testemunha interessante.


🧠 Confirmation Bias e Narrative Bias

Depois que temos hipótese,

montamos:

história.

O cérebro ama:

coerência.

Então fatos ambíguos:

ganham significado.

Narrative Bias.


🧠 Exemplo

DB2 warning
+
customer latency
+
old Db2 incident

Story:

Db2 again.

Mas:

talvez sejam:

três fatos não causais.


🎯 Pergunta Bellacosa nº 8

“Essa história explica os fatos ou os fatos foram escolhidos porque deixam a história bonita?”


🧠 Confirmation Bias e Metric Fixation

Leadership acredita:

service healthy.

Dashboard:

green.

Evidence:

green.

Customer complaints:

“anecdotal.”

Observe.

A crença:

“dashboard = reality”

é confirmada:

pelos próprios dashboards.

Circular.


☕ Se seu termômetro mede só a sala de reunião

não use:

para provar que cozinha não está pegando fogo.


🧠 McNamara Fallacy

Hard-to-measure:

ignored.

Quantitative evidence favorable:

dominates.


🎯 Pergunta Bellacosa nº 9

“Estamos descartando evidência porque é fraca ou porque é qualitativa?”


🧠 Confirmation Bias e Goodhart

Manager believes:

team improved.

KPI:

tickets closed +40%.

Great.

But:

reopens +80%.

Ignore.

Why?

Contradiz:

belief.


🧠 Counter-metric

Always ask:

what metric would:

tell opposite story?


🎯 Pergunta Bellacosa nº 10

“Qual indicador eu não gostaria de mostrar se minha narrativa estivesse errada?”

Boa.


🧠 Confirmation Bias e Goal Gradient

Projeto:

97%.

Queremos lançar.

Pass test:

“ótimo.”

Fail test:

“edge case.”

Percebe?

O mesmo evidence quality:

não.

Goal Gradient creates:

desired outcome.

Confirmation Bias:

selects supportive facts.


☕ “Edge case”

às vezes significa:

“evidência que estraga nosso cronograma.”


🧠 Confirmation Bias e Sunk Cost

Investimos:

18 meses.

Queremos:

continuar.

Então:

market signal positive:

important.

Negative:

temporary.

Sunk Cost + Confirmation.


🧠 Escalation of Commitment

Cada novo investimento:

aumenta desejo:

de estar certo.

Então:

evidência contrária:

fica psicologicamente cara.


🎯 Pergunta Bellacosa nº 11

“A evidência mudou ou apenas ficou mais difícil admitir que estamos errados?”


🧠 Confirmation Bias e Cultural Debt

Uma decisão antiga:

“centralizar tudo.”

Funcionou.

Hoje:

custos.

Mas organização lembra:

sucessos.

Fracassos alternativos:

superestimados.

Cultura confirma:

decisão.

Cultural Debt permanece.


☕ Uma cultura pode:

selecionar memória.


🧠 Confirmation Bias e arquitetura

Time cloud:

procura:

cloud success stories.

Time mainframe:

procura:

mainframe reliability stories.

Ambos:

podem estar certos.

Ambos:

podem estar incompletos.


🎯 Pergunta Bellacosa nº 12

“Estou comparando alternativas ou reunindo munição para a alternativa que já prefiro?”


🧠 Confirmation Bias e pessoas

Manager acha:

analista fraco.

Agora:

erros:

memorizados.

Acertos:

esperados.

Label:

strengthens.

This is dangerous.

Fundamental Attribution.

Halo/Horn.


☕ A pessoa vira:

query filter.


🧠 Confirmation Bias e AI

Agora:

zona moderna.

Prompt:

“Explique por que Db2 provavelmente causou o incidente.”

A IA:

faz exatamente isso.

E talvez faça:

muito bem.

O problema:

não é IA.

É:

pergunta.


🤖 LLMs são excelentes em construir argumentos plausíveis

Portanto:

não use apenas como:

advogado.

Use como:

adversário.


🧠 Prompt melhor

Avalie as hipóteses:
- Db2
- API externa
- MQ
- rede

Para cada uma, liste:
- evidências a favor
- evidências contra
- fatos não explicados
- teste que poderia refutá-la

Agora:

muito mais interessante.


🎯 Pergunta Bellacosa nº 13

“Estou pedindo análise ou justificativa?”


🧠 Confirmation Bias e RAG

Search query:

DB2 incident payment latency

Results:

Db2.

Surprise.

Se busca:

payment latency retries queue growth

espaço:

mais aberto.


☕ Query contém:

viés.

Banco de dados não:

reclama.


🧠 Confirmation Bias e AIOps

Classifier:

Db2 82%.

Operator:

opens Db2.

Finds:

warnings.

Confidence:

increases.

Mas:

machine and human

may use:

same source.

This is not:

independent confirmation.


🎯 Pergunta Bellacosa nº 14

“Essas confirmações são independentes ou todas derivam do mesmo dado?”

Importantíssima.


🧠 Três dashboards, uma fonte

RMF → dashboard A.

RMF → dashboard B.

RMF → AI model.

Three outputs.

One sensor.

Don't count:


COUNT(DASHBOARDS)

não é:

COUNT(INDEPENDENT_SOURCES).


🧠 Confirmation Bias e histórico

Historical RCA says:

Db2.

Current incident resembles.

Search old tickets tagged Db2.

Finds:

Db2.

But old labels may:

already be biased.

Circular confirmation.


🎯 Pergunta Bellacosa nº 15

“O histórico que usamos para confirmar esta hipótese foi classificado usando o mesmo raciocínio?”


🧠 Feedback loop em IA

OLD RCA LABEL
↓
TRAINING DATA
↓
MODEL PREDICTS SAME LABEL
↓
HUMAN ACCEPTS
↓
NEW RCA LABEL
↓
MORE TRAINING DATA

Isso é:

Confirmation Bias industrializado.


☕ Um erro histórico pode:

ganhar GPU.


🧠 Confirmation Bias e segurança

Analista acredita:

APT.

Procura:

PowerShell.

Encontra.

But PowerShell:

common.

Need:

base rate.

Context.


🧠 Base rate

Se signal:

common in healthy population,

weak evidence.


🎯 Pergunta Bellacosa nº 16

“Quão raro esse sinal realmente é?”


🧠 Security example

Alert:

failed logins.

Could mean:

attack.

Could mean:

password expired.

Need:

alternative hypotheses.


🧠 Confirmation Bias e fraude

Fraud analyst:

transaction suspicious.

Then every unusual action:

supports fraud.

Maybe:

traveling customer.

Again.


🧠 The hypothesis matrix

One of best tools.

EVIDENCE           DB2   API   MQ

Lock               +     0     0
Early timeout      -     +     0
Queue growth       0     +     +
Non-DB2 affected   -     +     0

Now:

explicit comparison.


☕ Uma hipótese sozinha

vence sempre.

Dê:

concorrentes.


🧠 Differential diagnosis

Medicine understands.

IT should:

steal shamelessly.


🎯 Pergunta Bellacosa nº 17

“Quais outras causas explicariam esses mesmos sintomas?”


🧠 Confirmation Bias e stop criteria

If we keep searching until:

find confirmation,

we will:

find.

Need:

predefined criteria.


🧠 Before test

Write:

If H1 true:

expect X.

If false:

expect Y.

Then:

test.


☕ Predeclare expected result

before:

seeing result.

Reduces:

rationalization.


🎯 Pergunta Bellacosa nº 18

“Antes do teste, registramos o que nos faria abandonar a hipótese?”


🧠 Interpretation elasticity

Danger:

whatever happens:

fits.

CPU up?

Db2.

CPU normal?

Db2 waiting.

Network normal?

Db2.

Network bad?

Db2 causing retries.

If everything:

supports,

nothing tests.


☕ Hipótese de borracha

esticando para caber:

em qualquer evidência.


🧠 Confirmation Bias e statistical cherry-picking

No need:

academic.

Simple:

choose:

time window;

metric;

customer segment;

baseline

that supports.

Sometimes:

unconscious.


🎯 Pergunta Bellacosa nº 19

“Por que escolhemos exatamente esse período, essa métrica e essa amostra?”


🧠 Confirmation Bias e visualization

Y-axis zoomed.

Spike:

dramatic.

Full scale:

small.

Charts can:

persuade.

Not lie exactly.

Frame.


☕ Gráfico também:

conta histórias.


🧠 Confirmation Bias e postmortem

After outcome known:

look back.

Pick events:

support final cause.

Hindsight Bias.

Narrative Bias.

Need:

preserve decision timeline.


🧠 What we believed when

Important:

02:30 H1 Db2 40%
02:40 API evidence found
02:45 H1 Db2 20%

Then:

learning.


🎯 Pergunta Bellacosa nº 20

“Estamos reconstruindo o raciocínio real ou escrevendo uma história elegante depois de saber o final?”


🧠 Confirmation Bias e Outcome Bias

Next chapter perhaps.

If risky change works:

we say:

“see? safe.”

One success:

confirms.

If fails:

opponents:

“see? dangerous.”

Outcome Bias + Confirmation.


☕ Um único resultado

pode alimentar:

duas religiões diferentes.


🧠 Confirmation Bias e Self-Serving

Success:

skill.

Failure:

context.

Then:

memory selects.


🧠 Confirmation Bias e Risk Compensation

Control introduced.

No incidents:

confirmation.

Team takes more risk.

Maybe risk hidden.


🎯 Pergunta Bellacosa nº 21

“Estamos confirmando que o controle funciona ou apenas observando que ainda não falhou?”


🧠 Confirmation Bias e backup

Backup:

green 365 days.

Belief:

safe.

Restore?

Never.

Logs:

confirm backup.

But objective:

recover.

Classic.


☕ Backup report confirma:

backup.

Não:

restore.


🧠 Confirmation Bias e DR

Tabletop exactly follows:

runbook.

Pass.

Confirms.

But real disaster:

different.

Need:

variation.

Challenge assumptions.


🎯 Pergunta Bellacosa nº 22

“Nosso teste foi construído para validar o plano ou para desafiar o plano?”


🧠 Confirmation Bias e training

Employee believes:

knows COBOL.

Course score:

95%.

Confirms.

Production challenge:

different.

Need:

labs.


🧠 Certification as evidence

Useful.

Not complete.

Metric Fixation.


☕ Badge diz:

“passou.”

Não:

“já viu todos os gremlins.”


🧠 Confirmation Bias em benchmark de IA

Model:

great benchmark.

We believe:

excellent.

Ignore:

real domain failures.

Again:

proxy.


🎯 Pergunta Bellacosa nº 23

“Estamos escolhendo avaliações que favorecem o modelo que já queríamos selecionar?”


🧠 Confirmation Bias e leadership

Leader says:

Db2.

Team wants:

please.

Evidence:

aligned.

Authority Bias.

Potential:

groupthink.


🧠 Speak-last rule

Leader:

listen first.

Then:

opinion.

Great.


☕ Quem tem mais autoridade

deveria ter:

mais cuidado

com a primeira frase.


🎯 Pergunta Bellacosa nº 24

“A equipe concorda porque viu a mesma evidência ou porque ouviu a mesma autoridade?”


🧠 Confirmation Bias e psychological safety

If challenging senior:

costly,

contra-evidence:

stays silent.

Now:

confirmation appears:

stronger.

Not because:

no contradiction.

Because:

contradiction suppressed.


☕ Silêncio não é:

consenso.

Às vezes:

é organograma.


🧠 Confirmation Bias e vendor

Client believes:

vendor fault.

Vendor believes:

client.

Both:

collect evidence.

Need:

shared timeline.

Independent instrumentation.


🎯 Pergunta Bellacosa nº 25

“Quem se beneficia se esta hipótese for aceita?”

Not automatic guilt.

But:

context.


🧠 Confirmation Bias e Principal-Agent

Incentives:

shape search.

Important.


🧠 Confirmation Bias e Campbell

If metric rewards:

certain root category,

pressure.


🧠 Confirmation Bias e Goodhart

If KPI:

low change failure,

teams classify:

incidents unrelated.

Now:

data confirms:

good changes.

Circular.


☕ Classificação também pode:

ser gaming.


🧠 Confirmation Bias em produção real

Imagine:

change 23:00.

Incident 23:15.

Everyone:

change.

Rollback.

Incident stays.

Now:

what?

If attached:

change,

may say rollback incomplete.

Maybe:

unrelated.

Need:

reopen.


🎯 Pergunta Bellacosa nº 26

“Qual evidência faria aceitarmos coincidência?”


🧠 Correlation vs causation

Still.

Important.


🧠 Confirmation Bias e code comments

Comment:

* FIX FOR DB2 ISSUE

Future developer:

assumes.

Maybe:

not.

Comments can:

anchor + confirm.


☕ Comentário velho

é:

opinião com fossilização.


🧠 Git history as evidence

Check:

why change?

Ticket?

Test?

Useful.


🧠 Confirmation Bias e documentation

Documentation may:

encode old theory.

Question.


🎯 Pergunta Bellacosa nº 27

“Esse documento descreve comportamento observado ou uma explicação histórica nunca revalidada?”


🧠 Confirmation Bias e Cultural Debt novamente

“Nunca altere esse módulo.”

Why?

Old outage.

Maybe:

cause wrong.

Fear:

confirmed by every avoided change.

No new evidence because:

nobody tests.

Self-sealing belief.


☕ Não mexemos porque:

é perigoso.

Como sabemos?

Porque:

nunca mexemos.

Maravilhoso circuito lógico.


🧠 Self-sealing beliefs

A belief structured so:

lack of challenge

becomes evidence.

Danger.


🎯 Pergunta Bellacosa nº 28

“Nossa crença impede justamente o experimento que poderia testá-la?”


🧠 Confirmation Bias e observability design

We instrument:

what we think important.

Then data says:

those things matter.

Why?

Because:

that's what measured.

McNamara.

Streetlight.


☕ Telemetria também:

herda hipótese.


🧠 Confirmation Bias e incident dashboards

If dashboard built:

Db2-centric,

incident appears:

Db2-centric.

Design:

matters.


🧠 End-to-end tracing

Better:

follow transaction.

Not:

component belief.


🎯 Pergunta Bellacosa nº 29

“Nossa observabilidade foi desenhada para o sistema real ou para a arquitetura mental que tínhamos quando o dashboard foi criado?”


🧠 Confirmation Bias e AI agents

Agent hypothesis:

Db2.

Then tool calls:

Db2.

Returns:

Db2 info.

Agent confidence:

rises.

This is:

tool-use feedback loop.

Need:

exploration policy.


🤖 Agent anti-confirmation

Require:

at least one disconfirming tool query.

At least:

one alternative hypothesis.

Very good.


🧠 Human-in-the-loop

Ask human:

what unexplained?

Useful.


🎯 Pergunta Bellacosa nº 30

“O agente possui um mecanismo para procurar deliberadamente evidência contra sua própria hipótese?”


🧠 Confirmation Bias e search engines

Search:

“why mainframes are obsolete”

Find:

arguments.

Search:

“why mainframes are essential”

Find:

arguments.

Search query:

decides:

universe.


☕ Internet é grande o suficiente

para confirmar:

quase qualquer coisa.


🧠 Better research query

“What are strengths, weaknesses and current use cases of mainframes?”

Neutraler.


🧠 Confirmation Bias e news

Same.

But let's stay:

mainframe.


🧠 Confirmation Bias e DBA vs app team

DBA:

“app.”

App:

“DB.”

Each:

protects domain.

Self-serving.

Need:

cross-team.


🎯 Pergunta Bellacosa nº 31

“Estamos procurando causa ou procurando inocência da nossa própria camada?”


🧠 Confirmation Bias e RCA blame

A person:

mistake.

Search:

their past mistakes.

Now:

“pattern.”

Maybe:

not.

Fundamental Attribution.


🧠 Blameless approach

Focus:

system.


☕ Você não precisa absolver pessoa

para:

entender contexto.


🧠 Confirmation Bias e hiring

Candidate with famous company.

We expect:

good.

Interpret answers:

favorably.

Halo.

Opposite too.

Not technical incident, but same mechanism.


🧠 Confirmation Bias e estimates

We believe:

project simple.

Then:

count only known tasks.

Unknowns:

ignored.

Planning fallacy.


🎯 Pergunta Bellacosa nº 32

“Nossa estimativa inclui aquilo que pode provar que o projeto é mais complexo do que gostaríamos?”


🧠 Confirmation Bias e No-Go

Team wants launch.

Evidence:

pass.

Fail:

exception.

Need:

predefined no-go.

This is:

cognitive forcing.


🧠 Precommitment

Define:

before:

emotion.


☕ Regra escrita ontem

pode proteger:

do cérebro de hoje.


🧠 Confirmation Bias e checklists

Checklist ensures:

look at:

contrary dimensions.

But beware:

box-ticking.

Need:

meaning.


🧠 Two-column checklist

SUPPORTS | CONTRADICTS

Simple.


🎯 Pergunta Bellacosa nº 33

“Qual é nossa melhor evidência contra a hipótese principal?”

If answer:

none,

ask:

why.


🧠 Confirmation Bias e confidence calibration

Use:

percentage maybe.

But avoid fake precision.

Maybe:

Low/Medium/High.

Update:

when new evidence.


🧠 Confidence should move both ways

Not only:

up.


☕ Hipótese também precisa:

saber perder.


🧠 Confirmation Bias e decision hygiene

A few excellent habits:

  • facts first

  • hypotheses later

  • independent opinions

  • contrary evidence

  • source provenance

  • baseline

  • timeline

  • re-estimation


🧠 Bellacosa Anti-Confirmation Protocol

Passo 1

Declare:

what you believe.

H1: Db2.

Passo 2

Declare:

why.


Passo 3

List:

at least two alternatives.


Passo 4

Write:

what would falsify H1.


Passo 5

Search:

contrary evidence first.


Passo 6

Compare:

baseline.


Passo 7

Check:

independent sources.


Passo 8

Ask:

someone unanchored.


Passo 9

Update:

confidence.


Passo 10

Reward:

being disproved early.


☕ Regra central

Ser refutado às 03:10 é muito mais barato que ser refutado às 07:30 por produção.


📋 Checklist Bellacosa anti-Confirmation Bias

[ ] Qual é nossa hipótese?

[ ] Que evidência a favor existe?

[ ] Que evidência contra existe?

[ ] Procuramos ativamente contradições?

[ ] Temos hipóteses concorrentes?

[ ] A evidência é independente?

[ ] Comparámos com baseline?

[ ] A timeline é consistente?

[ ] Há fatos não explicados?

[ ] O título do ticket nos ancorou?

[ ] O senior falou primeiro?

[ ] A IA recebeu a hipótese como fato?

[ ] O fix testou causalidade?

[ ] Existe incentivo para essa causa ser verdadeira?

[ ] Sabemos o que nos faria mudar de ideia?

🧠 Bellacosa Evidence Card

HYPOTHESIS:
_____________________________

SUPPORT:
_____________________________

CONTRADICTIONS:
_____________________________

ALTERNATIVES:
_____________________________

BASELINE:
_____________________________

INDEPENDENT SOURCES:
_____________________________

WOULD FALSIFY:
_____________________________

CONFIDENCE:
LOW / MEDIUM / HIGH

👻 Easter Egg nº 2 — o SQL do viés

Nosso jovem encontra:

SELECT *
  FROM EVIDENCE
 WHERE SUPPORTS_DB2 = 'Y';

Doctor:

— Problema?

— Sim.

Ele altera:

SELECT *
  FROM EVIDENCE
 ORDER BY EVENT_TIMESTAMP;

Doctor sorri.

— Agora?

Nosso jovem:

— Agora deixamos os dados falar antes da hipótese.

— Excelente.


🧠 O Teste do Inimigo

Imagine que:

você precisa provar:

sua própria hipótese errada.

Que evidência usaria?

Esse exercício:

é fantástico.


🧠 O Teste do Outro Time

Dê:

facts only.

Pergunte:

root hypothesis.

Compare.


🧠 O Teste do Dado Feio

Qual evidência:

mais atrapalha sua história?

Comece:

por ela.


🎯 Pergunta Bellacosa nº 34

“Qual fato eu gostaria secretamente que não existisse?”

Essa pergunta:

vale ouro.


🧠 Confirmation Bias e curiosity

Curiosidade genuína:

antídoto.

Instead:

“What confirms?”

Ask:

“What surprises?”


☕ O dado que surpreende

talvez seja:

o mais valioso.


🧠 Surprise is information

If model predicted:

A.

Observed:

B.

Don't rationalize.

Update:

model.


🧠 Engineer maturity

Junior:

tries to prove:

first guess.

Senior:

tries to break:

first guess.

Master:

enjoys when evidence:

forces new model.


☕ Porque:

estar certo

é bom.

Aprender algo novo:

melhor.


🕰️ De volta à War Room

03:44.

Nosso jovem escreve:

H1 DB2
H2 API
H3 MQ
H4 NETWORK

Then:

SUPPORT / CONTRADICT

DBA:

— Lock real.

Support Db2.

App:

— Timeout began 9 minutes earlier.

Contradict Db2 trigger.

Network:

— normal.

Contradict network.

MQ:

— queue increase after retries.

Supports API/retry.

Now:

investigation changes.


🔧 Resultado

External API latency:

trigger.

Retry mechanism:

amplifier.

Db2 lock:

secondary consequence.

All evidence:

real.

But meaning:

different.


☕ Essa é a parte importante

Confirmation Bias não necessariamente cria dados falsos. Ele pode criar interpretação falsa usando dados completamente verdadeiros.

Essa frase merece:

placa.


🧠 Data versus meaning

Logs:

fact.

Causal role:

interpretation.

Separate.


🎯 Pergunta Bellacosa nº 35

“O que é dado e o que é inferência nesta conclusão?”


👻 Easter Egg final — BELLACOSA.BIAS

No member:

BELLACOSA.BIAS(CONFIRMATION)

Código:

       IF HYPOTHESIS-EXISTS = 'Y'
           PERFORM SEARCH-SUPPORT
           PERFORM SEARCH-CONTRADICTION
           PERFORM GENERATE-ALTERNATIVES
       END-IF.

       IF CONTRADICTING-EVIDENCE > ZERO
           DISPLAY
           'DO NOT MOVE TO NOISE WITHOUT REVIEW'
       END-IF.

       IF TEAM-SAYS 'ISSO CONFIRMA'
           PERFORM ASK-WHAT-WOULD-REFUTE
       END-IF.

       IF ONLY-SUPPORT-WAS-SEARCHED = 'Y'
           MOVE 'BIASED'
             TO INVESTIGATION-STATUS
       END-IF.

Comentários:

* DO NOT ASK ONLY:
* WHY AM I RIGHT?

Outro:

* ASK:
* HOW COULD I BE WRONG?

Outro:

* TRUE DATA
* CAN SUPPORT
* WRONG STORIES.

Outro:

* THREE DASHBOARDS
* FED BY ONE SENSOR
* ARE STILL
* ONE SOURCE.

E naturalmente:

* DALEK THEORY:
* THE DOCTOR IS WRONG.
*
* DATASET:
* ONLY EVIDENCE
* SELECTED BY DALEKS.

Nosso jovem fecha:

o member.

Ri.


🧬 Regeneração organizacional

Uma organização madura não:

tenta eliminar Confirmation Bias.

Impossível.

Ela cria:

sistemas que dificultam:

sua vitória.

Facts first.

Independent review.

Alternative hypotheses.

Contradiction fields.

Base rates.

Timelines.

Fresh eyes.

Predefined criteria.

Blameless challenge.

Ela permite que alguém diga:

“Nossa hipótese favorita está errada.”

Sem:

drama.

Sem:

perda de status.

Sem:

“quem errou?”

Porque entende:

mudar de hipótese diante de evidência nova não é falha da investigação. É exatamente o comportamento que uma boa investigação deveria produzir.


📓 Diário do Doctor

Se guardar algumas coisas desta viagem:

Confirmation Bias é a tendência de procurar, lembrar e interpretar evidências de maneira consistente com crenças já existentes.

Ele pode afetar busca, atenção, memória, interpretação e comunicação.

Anchoring frequentemente cria a primeira hipótese que Confirmation Bias passa a proteger.

Recency Bias, Availability e Representativeness ajudam certas hipóteses a parecerem mais naturais.

Streetlight Effect determina onde procuramos.

Search Satisfaction faz um achado favorável reduzir a vontade de continuar.

Premature Closure transforma hipótese plausível em conclusão cedo demais.

Diagnosis Momentum distribui a conclusão pela organização.

Narrative Bias monta uma história coerente usando os findings favoráveis.

Metric Fixation pode fazer indicadores favoráveis parecerem mais confiáveis do que evidências qualitativas contrárias.

McNamara Fallacy pode excluir justamente aquilo que não é fácil de medir.

Goodhart e Campbell podem criar incentivos para selecionar classificações ou dados convenientes.

Sunk Cost e Escalation of Commitment tornam evidências contrárias psicologicamente caras.

A IA pode ser ancorada e induzida a confirmar a hipótese contida no prompt.

Múltiplas evidências derivadas da mesma fonte não são independentes.

Um finding verdadeiro pode sustentar uma interpretação causal errada.

E principalmente:

uma boa investigação não mede sua qualidade pela quantidade de evidências que conseguiu reunir a favor da hipótese; mede pela capacidade dessa hipótese de sobreviver às melhores evidências encontradas contra ela.


🥚 Último Easter Egg

Antes de entrar na TARDIS, o Doctor pergunta:

— Você quer estar certo?

Nosso jovem responde:

— Claro.

Doctor:

— Péssima prioridade.

— Como assim?

— Queira descobrir o que aconteceu.

— E se eu estiver errado?

Doctor abre a porta.

— Melhor ainda.

— Melhor?

“Significa que a realidade acabou de lhe ensinar algo que sua hipótese ainda não sabia.”

VWORP.

VWORP.

VWORP.

A TARDIS desaparece.

No quadro fica:

“Não procure provas de que está certo. Procure boas oportunidades de descobrir que está errado.”

E talvez essa seja a essência do Confirmation Bias no Bellacosa Mainframe:

a investigação começa com uma hipótese, mas só se torna engenharia quando essa hipótese recebe permissão real para morrer.

☕🌀

Próxima parada: Outcome Bias — quando uma decisão ruim termina bem, todo mundo passa a chamá-la de genial; e quando uma decisão boa termina mal por azar, todos juram que ela sempre foi irresponsável.

quarta-feira, 14 de maio de 2014

O CDN de Envelope Pardo: quando o office-boy Vaguinho distribuía conteúdo adulto na Avenida Paulista antes de alguém inventar a Internet

 

Bellacosa Mainframe e o famoso contrabando de envelopes pardos

☕ Um Café no Bellacosa Mainframe

O CDN de Envelope Pardo: quando o office-boy Vaguinho distribuía conteúdo adulto na Avenida Paulista antes de alguém inventar a Internet

📦 No coração financeiro do Brasil, entre bancos, multinacionais e executivos engravatados, existia uma rede paralela de distribuição cujo protocolo era simples: dinheiro na mão, discrição e jamais perguntar o que havia dentro do envelope.

Hoje você abre um navegador.

Digita alguma coisa.

O pedido atravessa roteadores, fibras ópticas, datacenters, caches e CDNs distribuídos pelo planeta.

Milissegundos depois, o conteúdo aparece.

É maravilhoso.

Mas houve uma época em que determinadas redes de distribuição funcionavam com uma tecnologia consideravelmente mais sofisticada:

um moleque de sapato gasto carregando um envelope pardo pela Avenida Paulista.

Eu conhecia o protocolo.

Porque o moleque era eu.

Ou melhor:

Vaguinho.

Office-boy.

Mensageiro.

Transportador de documentos.

E, ocasionalmente, por alguns trocados adicionais...

CDN humano de material adulto.

Bem-vindo à Internet brasileira antes da Internet.


🏙️ Avenida Paulista: o datacenter do capitalismo brasileiro

Precisamos primeiro reconstruir o cenário.

A Avenida Paulista daquela época era um dos grandes símbolos do poder econômico brasileiro.

Bancos.

Seguradoras.

Multinacionais.

Grandes escritórios.

Empresas nacionais.

Executivos.

Advogados.

Contadores.

Gerentes.

Diretores.

Secretárias.

Telefonistas.

Contínuos.

Office-boys.

Era um universo de terno, gravata, telefone fixo, máquina de escrever, memorando, protocolo, carimbo e papel.

Muito papel.

Toneladas de papel.

Documentos circulavam fisicamente entre empresas.

Contratos.

Faturas.

Cheques.

Relatórios.

Correspondência.

Um documento que hoje atravessaria São Paulo como PDF precisava ganhar pernas.

E as pernas frequentemente pertenciam a nós:

os office-boys.


🏃 O TCP/IP usava sapatos

O office-boy era uma peça fundamental da infraestrutura corporativa.

Hoje alguém clica:

SEND.

Naquela época:

— Vaguinho!

— Oi.

— Leva isso na Paulista.

E lá ia Vaguinho.

SOURCE:
EMPRESA A

DESTINATION:
EMPRESA B

PROTOCOL:
OFFICE-BOY

TRANSPORT:
ÔNIBUS + METRÔ + PERNAS

PACKET:
ENVELOPE

TRACKING:
"JÁ VOLTO."

SLA:
ANTES DAS CINCO

🤣

Se o office-boy faltasse, determinadas partes da rede simplesmente apresentavam degradação de serviço.

Éramos middleware com vale-transporte.


📦 E então surgiu o envelope pardo

O envelope pardo era uma obra-prima da tecnologia da informação.

Barato.

Resistente.

Discreto.

Compatível com praticamente qualquer empresa.

Não revelava o conteúdo.

Não precisava de senha.

Não tinha preview.

Não mandava notificação.

E ninguém recebia:

“Vagner compartilhou um arquivo com você.”

O envelope simplesmente chegava.

ENCRYPTION:
OPACITY

ACCESS CONTROL:
DESTINATÁRIO

METADATA:
MINIMAL

CONTENT INSPECTION:
SOCIALMENTE DESENCORAJADA

Era praticamente criptografia por constrangimento.

🤣

E foi nesse ambiente que descobri que havia tráfego adicional disponível na rede.


😏 O Brasil oficial tinha um segundo sistema operacional

Durante esta nossa arqueologia sobre Carlos Zéfiro, Grafipar e Carol Blue, uma coisa ficou cada vez mais clara para mim.

Existia o Brasil oficial.

E existia outro Brasil executando silenciosamente em background.

No Brasil oficial havia:

reuniões;

balancetes;

memorandos;

hierarquias;

chefes;

gravatas;

recepcionistas;

departamentos financeiros.

No Brasil paralelo havia:

piadas;

revistas;

bebidas;

jogo;

namoros;

fofocas;

fantasias;

publicações adultas;

e toda aquela infinita humanidade que desaparecia imediatamente quando o diretor abria a porta e perguntava:

— Como estão os números deste trimestre?

🤣

O mesmo homem podia existir perfeitamente nos dois ambientes.

Às nove:

Doutor Fulano, Diretor Financeiro.

Às quatro:

— Chegou aquele negócio?

Pessoas são pessoas.

A gravata nunca corrigiu isso.


🧑‍💼 O office-boy sabia coisas

Existe um detalhe da cultura corporativa antiga que talvez seja difícil explicar hoje.

O office-boy circulava.

Subia.

Descia.

Entrava.

Saía.

Conversava com recepcionistas.

Conhecia outros office-boys.

Conhecia bancas.

Conhecia caminhos.

Sabia onde ficavam empresas.

Sabia quem recebia documentos.

Sabia onde entregar.

E sobretudo:

era invisível o suficiente para circular por quase todos esses mundos.

Não era executivo.

Não participava das decisões.

Mas atravessava os corredores onde elas aconteciam.

Isso transformava o office-boy num tipo curioso de nó de rede.

             [BANCO]
                |
[ESCRITÓRIO]--VAGUINHO--[SEGURADORA]
                |
          [MULTINACIONAL]
                |
              [BANCA]

Centralidade de grafo surpreendentemente alta.

Salário surpreendentemente baixo.

🤣


💰 E o jovem empreendedor descobre o mercado

Em algum momento, Vaguinho percebeu uma das leis fundamentais do capitalismo:

se existe demanda e alguém consegue entregar, existe negócio.

Não fundei uma startup.

Não fiz apresentação para investidores.

Não havia venture capital.

Não existia LinkedIn para publicar:

“Tenho enorme satisfação em anunciar minha nova jornada empreendedora.”

🤣

Existia apenas:

material;

interessado;

entrega;

alguns trocados.

O modelo de negócios cabia inteiro numa folha de caderno.

RECEITA =
VALOR RECEBIDO
-
CUSTO

IF RECEITA > 0
    MOVE RECEITA TO BOLSO-DO-VAGUINHO
END-IF

Nascia o capitalismo de envelope pardo.


📰 Mas de onde vinha aquele ecossistema?

Agora, décadas depois, consigo enxergar aquilo com outros olhos.

Eu estava no final de uma cadeia muito maior.

Antes de chegar ao envelope havia:

editoras;

gráficas;

fotógrafos;

modelos;

desenhistas;

roteiristas;

distribuidores;

bancas;

revendedores;

colecionadores;

compradores.

Carlos Zéfiro já havia mostrado décadas antes que existia público para quadrinhos eróticos clandestinos.

Depois surgiram estruturas editoriais muito mais profissionais.

A Grafipar produziu revistas, quadrinhos e fotonovelas.

Carol Blue circulou pelas bancas.

Outras publicações disputavam aquele mercado.

Portanto o envelope que atravessava a Paulista não surgiu espontaneamente.

Atrás dele existia uma indústria cultural.


🖥️ Era um CDN

Décadas depois, quando comecei a trabalhar com informática, descobri um nome maravilhoso:

Content Delivery Network.

Uma CDN coloca conteúdo mais perto do usuário para distribuí-lo de maneira eficiente.

Quando finalmente compreendi o conceito, deveria ter levantado a mão:

— Professor...

— Sim?

— Isso existe há décadas.

— Como assim?

Eu fazia isso na Paulista.

🤣🤣🤣

Pense na arquitetura.

             ORIGIN
                |
                v
          DISTRIBUIDOR
                |
                v
             BANCA
                |
                v
          REDE INFORMAL
                |
                v
            VAGUINHO
                |
       +--------+--------+
       |        |        |
       v        v        v
    CLIENTE  CLIENTE  CLIENTE

Edge computing.

O conteúdo ficava próximo do consumidor.

E o edge tinha pernas.


🔐 HTTPS? Não. HPS.

Também existia segurança.

Não criptográfica.

Social.

O destinatário não precisava explicar o conteúdo.

O transportador não precisava fazer perguntas.

O envelope não precisava anunciar nada.

Era uma espécie de acordo tácito.

HPS/1.0

HUMAN PRIVACY SYSTEM

RULE 1:
ENTREGAR.

RULE 2:
RECEBER.

RULE 3:
NÃO PERGUNTAR.

RULE 4:
NÃO ABRIR.

RETURN CODE:
0000

E funcionava.

Porque privacidade também pode ser construída através de convenções sociais.


🕴️ O executivo também era Homo sapiens

Essa talvez tenha sido uma das primeiras grandes aulas antropológicas que recebi sem perceber.

Quando somos jovens, imaginamos adultos importantes como criaturas diferentes.

Diretores.

Executivos.

Gerentes.

Advogados.

Banqueiros.

Homens de terno.

Pareciam pertencer a outra espécie.

Depois descobrimos:

não.

🤣

O sujeito podia administrar milhões durante o expediente e continuar sendo exatamente o mesmo primata curioso que todos os outros depois que fechava a porta.

A civilização cria cargos.

A biologia continua rodando embaixo.

IDENTIFICATION DIVISION.

PROGRAM-ID. EXECUTIVO.

ENVIRONMENT DIVISION.
    CORPORATE.

DATA DIVISION.
    HUMAN-BEING PIC X VALUE 'Y'.

O HUMAN-BEING nunca deixava de ser Y.


🏢 E isso acontecia no coração do sistema

Esse detalhe torna a memória particularmente engraçada.

Não estamos falando de uma viela obscura numa cidade distante.

Era a Avenida Paulista.

Um dos grandes centros financeiros do Brasil.

Enquanto enormes quantidades de dinheiro circulavam contabilmente dentro dos prédios...

pequenos envelopes pardos circulavam fisicamente entre pessoas.

Duas economias.

Uma registrada nos sistemas corporativos.

Outra registrada apenas na memória dos participantes.

PAULISTA ONLINE

TRANSACTION 001:
R$ 15.000.000
CORPORATE FINANCE

TRANSACTION 002:
uns trocados
ENVELOPE PARDO

AUDIT STATUS:
TRANSACTION 002 NOT FOUND

🤣


🧒 E Vaguinho estava aprendendo

O mais curioso é olhar para aquele garoto agora.

Ele provavelmente achava que estava apenas conseguindo algum dinheiro extra.

Mas estava aprendendo coisas que só reconheceria décadas depois.

Logística.

Era necessário entregar.

Confiança.

O envelope precisava chegar intacto.

Privacidade.

Não se discutia o conteúdo no corredor.

Rede social.

Era preciso conhecer pessoas.

Demanda.

Só existia negócio porque alguém queria comprar.

Reputação.

Se você não fosse confiável, o circuito terminava.

Sem MBA.

Sem PowerPoint.

Sem Scrum Master.

Sem daily meeting.

🤣

Apenas produção.


🧙‍♂️ E o mais engraçado: depois veio o mainframe

O roteirista da minha vida tem um senso de humor peculiar.

O garoto que atravessava São Paulo transportando pacotes acabou entrando profissionalmente no mundo dos grandes sistemas.

Mainframes.

Bancos.

Processamento.

Redes.

Segurança.

Dados.

Transações.

SLA.

Auditoria.

Controle de acesso.

E décadas depois olha para trás e percebe:

eu já trabalhava com transporte de informação antes de saber o que era informação distribuída.

Só que o protocolo era:

VAGUINHO/1.0.


📡 Antes do P2P havia P2P

Também havia outra característica daquela época que desapareceu parcialmente com a Internet.

O compartilhamento físico.

Uma revista podia ter vários leitores.

Um comprava.

Outro via.

Outro pegava emprestado.

Outro descobria onde conseguir.

A informação percorria uma rede humana.

PESSOA
  ↓
PESSOA
  ↓
PESSOA
  ↓
PESSOA

Peer-to-peer.

Literalmente.

Pessoa para pessoa.

Quando décadas depois surgiram BBS, FTP, Usenet, eMule, BitTorrent e outras tecnologias, o comportamento não nasceu com os computadores.

A tecnologia apenas acelerou uma coisa antiquíssima:

“Tenho algo interessante. Quer ver?”


🏺 E agora percebo que aquilo também era História

Na época não parecia.

Era cotidiano.

Era molecagem.

Era algum dinheiro extra.

Era mais uma pequena aventura na cidade.

Mas décadas depois aqueles envelopes ajudam a reconstruir um Brasil que desapareceu.

O Brasil das bancas.

Dos office-boys.

Dos documentos físicos.

Dos elevadores cheios de gente fumando.

Dos telefones fixos.

Das secretárias.

Dos contínuos.

Dos departamentos enormes.

Dos envelopes circulando de prédio em prédio.

E de uma sociedade muito mais conservadora publicamente do que sua vida privada sugeria.


📦 O envelope como artefato arqueológico

Imagine um arqueólogo de 2526 encontrando um envelope pardo intacto.

Ele poderia escrever:

“Objeto administrativo utilizado pelas corporações brasileiras do final do século XX para transporte de documentos.”

Correto.

Mas incompleto.

🤣

Porque o objeto possuía usos que jamais apareceriam no manual.

É exatamente o mesmo problema que encontramos quando estudamos Roma.

Encontramos um objeto.

Classificamos.

Uso doméstico.

Uso religioso.

Uso administrativo.

Mas pessoas sempre encontram usos adicionais para tecnologias.

Talvez algum romano também tivesse sua versão do envelope pardo.

Provavelmente tinha.

Pessoas são pessoas.


😂 E ninguém imaginava o futuro

Essa talvez seja minha parte favorita.

Imagine alguém parando o jovem office-boy:

— Vaguinho.

— Oi.

— Um dia existirá uma rede mundial de computadores.

— Tá.

— Bilhões de pessoas estarão conectadas.

— Certo.

— Poderão transmitir textos, fotografias e vídeos instantaneamente.

— Legal.

— E você escreverá sobre tudo isso décadas depois.

Silêncio.

Quanto você paga pela entrega?

🤣🤣🤣

Prioridades.


🧬 Do envelope ao pacote IP

A evolução tecnológica fica maravilhosa quando colocamos lado a lado.

1980s

PAYLOAD:
PAPEL

PACKET:
ENVELOPE PARDO

ROUTER:
OFFICE-BOY

NETWORK:
RUAS DE SÃO PAULO

LATENCY:
30–120 MINUTOS

BANDWIDTH:
LIMITADA PELO BRAÇO

SECURITY:
NÃO ABRA

PROTOCOL:
CONFIANÇA


2026

PAYLOAD:
BITS

PACKET:
IP

ROUTER:
ROUTER

NETWORK:
INTERNET

LATENCY:
MILISSEGUNDOS

BANDWIDTH:
GIGABITS

SECURITY:
TLS

PROTOCOL:
MATEMÁTICA

Mudamos tudo.

E não mudamos quase nada.

Existe origem.

Existe destino.

Existe conteúdo.

Existe transporte.

Existe privacidade.

Existe confiança.

Existe gente querendo receber alguma coisa.


☕ O último café

Quando lembro daquele garoto atravessando a Avenida Paulista, não consigo deixar de rir.

Ele não sabia que trabalharia com computadores.

Não sabia o que era TCP/IP.

Não conhecia CDN.

Não conhecia criptografia.

Não sabia o que significava P2P.

Não imaginava smartphones.

Não imaginava streaming.

Não imaginava que um dia alguém conseguiria acessar praticamente qualquer conteúdo do planeta sem sair da cadeira.

Ele conhecia algo muito mais simples.

Alguém queria uma coisa.

Outra pessoa tinha.

Precisava chegar de A até B.

E havia alguns trocados envolvidos.

Pronto.

Arquitetura implementada.

Décadas depois podemos desenhar o sistema:

        BRASIL OFICIAL
             |
     AVENIDA PAULISTA
             |
    +--------+--------+
    |                 |
CORPORAÇÕES       VIDA HUMANA
    |                 |
DOCUMENTOS       CURIOSIDADES
    |                 |
    +--------+--------+
             |
          VAGUINHO
             |
      ENVELOPE PARDO
             |
         ENTREGA

Talvez essa seja uma das melhores lembranças daquela época.

Não pelo conteúdo dos envelopes.

Mas pelo que eles revelam.

Por trás dos prédios espelhados, das gravatas, dos cargos e dos organogramas existia exatamente a mesma humanidade que encontramos nos catecismos de Carlos Zéfiro, nas revistas da Grafipar, nas bancas e em qualquer outra época da História.

Mudam as tecnologias.

Mudam as roupas.

Mudam os prédios.

Mudam os protocolos.

O usuário permanece assustadoramente retrocompatível.

E durante algum tempo, antes de alguém inventar a World Wide Web, uma pequena parte daquela rede brasileira teve um servidor de borda muito particular.

Não possuía endereço IP.

Não tinha fibra.

Não tinha cache.

Não tinha certificado digital.

Tinha pernas.

Tinha vale-transporte.

Atendia por Vaguinho.

E aceitava pagamento em dinheiro.

DELIVERY COMPLETE.

RETURN CODE = 0000.

☕📦

terça-feira, 13 de maio de 2014

Rance: quando os RPGs japoneses rodavam no PC-98 e ninguém ainda tinha inventado a palavra isekai

 

Bellacosa Mainframe apresenta rance 01

☕ Um Café no Bellacosa Mainframe

Rance: quando os RPGs japoneses rodavam no PC-98 e ninguém ainda tinha inventado a palavra isekai

⚔️ Antes de Subaru morrer. Antes de Rudeus reencarnar. Antes de Kazuma encontrar a Aqua. Antes de alguém gritar “STATUS!” e aparecer uma tela azul flutuando no meio da floresta... havia um sujeito chamado Rance.

Por Vagner Bellacosa


Imagine a seguinte situação.

Você entra numa máquina do tempo.

Não numa TARDIS.

Hoje não.

Vamos utilizar uma máquina muito mais perigosa.

Um NEC PC-9801.

Ajustamos o capacitor de fluxo para o Japão de 1989, colocamos um disquete na unidade, ouvimos aquele maravilhoso barulho mecânico que para os jovens atuais provavelmente parece uma impressora possuída por um demônio e digitamos alguma coisa no teclado.

A tela aparece.

Não existe Steam.

Não existe Crunchyroll.

Não existe smartphone.

Não existe Wi-Fi.

Não existe ChatGPT.

Não existe sequer a ideia moderna de que você vai morrer atropelado por um caminhão e acordar cinco minutos depois em outro universo acompanhado por uma deusa com sérios problemas administrativos.

Mas existe fantasia.

Existem aventureiros.

Existem reinos.

Existem monstros.

Existem magos.

Existem quests.

Existem personagens recorrentes.

Existe um mundo que vai sendo expandido jogo depois de jogo.

E existe um aventureiro chamado Rance.

Bem-vindo a uma das escavações arqueológicas mais estranhas que já fizemos perto da máquina de café.

Porque, olhando para Rance hoje, é muito fácil enxergar apenas aquilo que está na superfície:

“Ah. É aquele eroge antigo.”

Sim.

É.

Mas parar aí seria mais ou menos como encontrar um IBM System/360 num museu e concluir:

“Ah. É aquele computador velho que não roda Chrome.”

Tecnicamente você talvez não esteja completamente errado.

Historicamente você perdeu praticamente tudo.



☕ Café servido. Vamos voltar para 1989.

O primeiro Rance: Hikari wo Motomete foi lançado pela AliceSoft em 1989.

E não estamos falando de uma franquia criada recentemente tentando parecer retrô.

Estamos falando de 1989 de verdade.

O próprio site oficial da AliceSoft, ao apresentar décadas depois o remake Rance 01, identifica explicitamente a obra como reconstrução do jogo lançado em 1989. O remake preservou a estrutura de aventura baseada em seleção de comandos, mas refez cenários, gráficos, combate e som.

Pare um segundo e pense nessa data.

O Game Boy estava chegando ao mercado.

O Mega Drive tinha acabado de aparecer no Japão.

A World Wide Web ainda não existia publicamente.

Linux não existia.

Windows 3.0 ainda não existia.

Java não existia.

Python não existia.

E o COBOL?

O COBOL olhava para toda essa garotada e dizia:

— Segurem meu café.

😆

Enquanto isso, no Japão, computadores pessoais como NEC PC-98, Sharp X68000, MSX e posteriormente FM Towns estavam ajudando a construir uma cultura de jogos bastante diferente daquela que nós, no Ocidente, associamos imediatamente aos consoles japoneses.

Quando pensamos no Japão dos videogames daquela época, normalmente lembramos de:

Nintendo.

Sega.

Famicom.

Mega Drive.

Arcades.

Mario.

Dragon Quest.

Final Fantasy.

Mas havia outro Japão digital acontecendo dentro dos quartos, escritórios e pequenas software houses.

Era o Japão do computador pessoal.

E ali floresceu um ecossistema peculiar de adventure games, RPGs, visual novels primitivas e jogos adultos.

Rance nasceu exatamente nesse terreno.

Registros de lançamento apontam o primeiro jogo para PC-98 em julho de 1989, e a franquia passaria por máquinas como PC-98, MSX, X68000 e FM Towns.

Isso é importante.

Porque Rance não apareceu depois que todos os padrões modernos do RPG japonês estavam perfeitamente definidos.

Ele cresceu junto com eles.



🖥️ O PC-98 era o “mainframe doméstico” dessa história

Calma.

Antes que algum historiador da computação derrube o café:

não estou dizendo que PC-98 era mainframe.

😆

Estou dizendo que, para nossa analogia Bellacosa, ele representa aquela máquina de uma geração anterior que continua escondendo universos inteiros de software que muita gente moderna simplesmente desconhece.

O NEC PC-9800 foi uma família extremamente importante na computação pessoal japonesa.

E existe uma razão pela qual tantos jogos japoneses antigos parecem ter vivido numa dimensão paralela.

Eles realmente viveram.

O mercado japonês de computadores tinha particularidades de hardware, resolução gráfica, tratamento de caracteres japoneses e padrões próprios.

Portanto, muitos programas ficavam praticamente confinados ao Japão.

Era uma espécie de:

IF COUNTRY = JAPAN
    PERFORM CULTURAL-REVOLUTION
ELSE
    CONTINUE
END-IF.

Nós, no Brasil, recebíamos muito mais facilmente aquilo que atravessava o oceano pelos consoles.

Nintendo chegava.

Sega chegava.

PlayStation chegaria.

Mas milhares de experiências criadas para computadores japoneses permaneceriam invisíveis para grande parte do público ocidental.

Rance era uma delas.



⚔️ Mas afinal, quem diabos é Rance?

Aqui começa o problema.

Porque Rance não é exatamente o protagonista que você apresentaria para sua mãe dizendo:

— Veja que rapaz educado.

Muito menos para o departamento de Recursos Humanos.

Rance foi deliberadamente construído como um personagem extremamente egoísta, arrogante, sexualmente obsessivo e moralmente problemático.

A própria descrição oficial da AliceSoft não tenta transformá-lo retroativamente num cavaleiro virtuoso.

Muito pelo contrário.

O jogo assume a natureza absurda do personagem desde o princípio.

Ele é praticamente uma desconstrução do herói clássico.

O cavaleiro tradicional pensa:

“Preciso salvar a princesa!”

Rance pensa algo mais próximo de:

“Tem princesa?”

Missão secundária detectada.

😂

E aqui precisamos separar duas coisas.

Personagem interessante não significa pessoa admirável.

Rance funciona justamente porque frequentemente é aquilo que o herói convencional não deveria ser.

Ele não é Link.

Não é Aragorn.

Não é Luke Skywalker.

Ele está muito mais próximo daquele jogador de RPG de mesa que o mestre observa entrando na taverna e pensa:

“Meu Deus... o que esse desgraçado vai fazer agora?”



🎲 Rance é quase o jogador que escapou da mesa de RPG

Essa talvez seja uma das maneiras mais divertidas de entender o personagem.

Imagine uma campanha de RPG.

O mestre preparou:

  • uma guerra entre reinos;

  • uma antiga profecia;

  • uma princesa desaparecida;

  • uma conspiração política;

  • três masmorras;

  • uma civilização perdida;

  • um poderoso artefato mágico.

E o jogador pergunta:

— A garçonete da taverna é bonita?

O mestre fecha os olhos.

Respira.

Olha para as 48 páginas de campanha que escreveu durante o fim de semana.

— É.

— Quero conversar com ela.

Pronto.

Nasceu Rance.

😂

Só que existe algo fascinante nisso.

Enquanto o protagonista se comportava como uma força caótica, o mundo ao redor dele continuava crescendo.

E isso se tornaria uma das características mais interessantes da franquia.



🌍 O verdadeiro protagonista talvez seja o mundo

Aqui Rance começa a ficar historicamente interessante.

Porque uma franquia iniciada em 1989 teve décadas para acumular:

reinos,

guerras,

personagens,

facções,

demônios,

sistemas políticos,

geografia,

relações internacionais,

religião,

magia,

história,

alianças,

inimigos,

consequências.

Aquilo que começa parecendo uma aventura relativamente simples ganha uma enorme quantidade de worldbuilding acumulado.

Programador mainframe conhece perfeitamente esse fenômeno.

Você entra num sistema e alguém diz:

— É um programinha simples.

Quando você abre:

PGM001
   |
   +-- CALL PGM017
          |
          +-- CALL PGM233
                 |
                 +-- READ ARQUIVO HISTÓRICO
                 |
                 +-- EXEC CICS LINK
                 |
                 +-- DB2
                 |
                 +-- MQ

Você pergunta:

— Quando fizeram isso?

— A primeira versão?

— Sim.

— 1989.

😳

EXATAMENTE.

Rance virou uma espécie de sistema legado narrativo.

Cada nova versão adicionou regras.

Personagens permaneceram.

Eventos anteriores ganharam consequências.

O mapa ficou maior.

O lore ficou mais complexo.

Décadas depois, aquele “programinha simples” tinha se transformado numa plataforma.



🧙 Antes do isekai moderno havia o RPG de fantasia

Agora chegamos à parte deliciosa da arqueologia.

Hoje reconhecemos instantaneamente determinadas estruturas:

Guilda dos aventureiros.

Quest.

Ranking.

Magia.

Demônios.

Reinos.

Party.

Dungeon.

Skills.

Níveis.

Heróis moralmente duvidosos.

Personagens recorrentes.

Grandes mapas.

Mas precisamos tomar cuidado para não cometer um erro histórico.

Esses elementos não nasceram no isekai.

O isekai moderno herdou uma enorme quantidade deles de tradições anteriores.

RPGs de mesa.

Dungeons & Dragons.

Wizardry.

Ultima.

Dragon Quest.

Final Fantasy.

RPGs japoneses para computador.

Light novels.

Mangás de fantasia.

Adventure games.

E toda uma cultura otaku que foi misturando essas referências durante décadas.

Portanto:

RPG ocidental
      |
      v
RPG japonês
      |
      +--> Console RPG
      |
      +--> Computer RPG
              |
              +--> Adventure
              |
              +--> Visual Novel
              |
              +--> Eroge

E as fronteiras nunca foram perfeitamente rígidas.

Rance vive justamente numa dessas interseções.


🚚 Truck-kun ainda estava na autoescola

Em 1989 ninguém precisava morrer atropelado para entrar naquele mundo.

Você simplesmente:

ligava o computador.

Esse é um ponto que adoro.

Hoje a narrativa isekai frequentemente precisa construir uma ponte:

MUNDO REAL
    |
    | Truck-kun
    v
OUTRO MUNDO

Rance não precisa disso.

O universo fantástico é a realidade narrativa do personagem.

Não existe funcionário de escritório japonês reencarnado.

Não existe smartphone transportado.

Não existe menu mágico explicado como videogame porque o protagonista jogava MMORPG.

O mundo simplesmente existe.

Isso muda bastante a relação entre personagem e cenário.

Rance não chega dizendo:

— Ah! Isso funciona como um RPG!

Ele vive dentro daquela lógica.


💾 O jogador, porém, é o verdadeiro isekai

E aqui aparece uma interpretação divertida.

Talvez Rance não precise ser transportado para outro mundo.

Nós somos transportados.

Colocamos o disquete.

Ligamos o PC.

Carregamos o jogo.

E atravessamos o portal.

O monitor CRT é o nosso círculo mágico.

O teclado é nosso artefato encantado.

O disquete é o grimório.

E o AUTOEXEC.BAT...

Bom...

Esse é claramente um pergaminho proibido.

😂


🧬 De Rance até Mushoku Tensei?

Aqui precisamos evitar aquela genealogia simplista da Internet:

Rance
   |
   v
Mushoku Tensei
   |
   v
Todos os isekais

Não.

História cultural raramente funciona assim.

Influência é muito mais parecida com um grafo do que com uma PROC chamando um único programa.

Há inúmeras obras, jogos, autores e tradições se influenciando simultaneamente.

Mas existe uma conexão interessante.

Fontes sobre as influências declaradas de Rifujin na Magonote, criador de Mushoku Tensei, mencionam Rance entre os jogos que contribuíram para sua formação criativa.

Isso não significa que Rudeus seja “Rance 2.0”.

Nem que Mushoku Tensei seja uma cópia.

Significa algo muito mais interessante:

ideias sobrevivem.

Um jovem joga alguma coisa.

A experiência fica armazenada.

Anos depois ele escreve outra obra.

Mistura aquela memória com dezenas de outras referências.

Outra pessoa lê.

Cria outra história.

Outra geração assiste.

E assim cultura funciona.

É quase um gigantesco:

MOVE CULTURA-ANTERIOR
  TO MEMORIA-CRIATIVA.

COMPUTE NOVA-OBRA =
        EXPERIENCIA
      + REFERENCIAS
      + IMAGINACAO
      + CONTEXTO-HISTORICO.

Nenhuma variável contém tudo.

Mas nenhuma existe completamente sozinha.


🧠 Isso é praticamente um grafo cultural

Imagine os nós:

Wizardry
Ultima
Dragon Quest
PC-98
AliceSoft
Rance
Visual Novels
Eroge
Light Novels
Narou
Mushoku Tensei
Konosuba
Isekai moderno

Agora desenhe milhares de arestas.

Algumas fortes.

Algumas fracas.

Algumas documentadas.

Algumas apenas contextuais.

Pronto.

Você acabou de transformar a história da cultura otaku num banco Neo4j.

😂

MATCH (r:Rance)-[:INFLUENCED*1..5]->(x)
RETURN x

O problema é que provavelmente a query nunca termina.


📀 2013: alguém decidiu recompilar o legado

Décadas depois do original, a AliceSoft voltou ao começo.

Em 27 de setembro de 2013, lançou Rance 01: Hikari wo Motomete para Windows, classificando-o oficialmente como ADV+RPG.

E isso é maravilhoso para nossa analogia mainframe.

Não foi simplesmente:

COPY OLD-RANCE NEW-RANCE

A própria AliceSoft explica que manteve a ideia da aventura baseada em comandos, mas reconstruiu elementos como cenário, gráficos, sistema de batalha e som.

Em linguagem corporativa:

modernização de aplicação legada.

😂

Temos:

RANCE 1989
    |
    | análise funcional
    | preservação das regras
    | redesign
    | novo frontend
    | novo motor
    v
RANCE 01 - 2013

Não é muito diferente conceitualmente daquela reunião em que alguém diz:

— Precisamos modernizar esse sistema COBOL.

E você pergunta:

— Podemos alterar as regras?

— NÃO!

— Podemos alterar os dados?

— NÃO!

— Podemos mudar o comportamento?

— NÃO!

— Então o que exatamente vamos modernizar?

— A tela.

😆


🏺 Software também é arqueologia cultural

Esse talvez seja o ponto mais importante desta conversa.

Jogos antigos não são apenas entretenimento velho.

São documentos históricos executáveis.

Um jogo preserva:

interfaces,

limitações técnicas,

humor,

estética,

expectativas sociais,

modelos narrativos,

decisões de design,

capacidade gráfica,

formas de distribuição,

hábitos de consumo,

linguagem.

É uma cápsula do tempo.

Quando executamos um programa de 1989, não estamos apenas executando código.

Estamos executando uma pequena parte de 1989.

Isso vale para Rance.

Vale para Prince of Persia.

Vale para Doom.

Vale para Adventure.

Vale para MUDs.

Vale para softwares corporativos.

E vale, de uma maneira muito peculiar, para COBOL.


🧓 Rance e COBOL têm algo estranhamente em comum

Calma.

Eu consigo explicar.

😂

Ambos sobreviveram muito mais tempo do que alguém olhando apenas para a tecnologia original poderia imaginar.

COBOL:

1959 → 2026.

Rance:

1989 → décadas de continuidade e remakes.

E ambos demonstram uma regra frequentemente esquecida:

software sobrevive quando existe um ecossistema em torno dele.

Não basta código.

Existem usuários.

Conhecimento.

História.

Dados.

Processos.

Comunidade.

Valor acumulado.

No caso de uma franquia de jogos, temos personagens, lore e fãs.

No sistema corporativo temos regras de negócio, dados históricos e integrações.

Mas o fenômeno de continuidade possui uma semelhança curiosa.


🧟 “Por que não fizeram tudo novamente?”

Todo programador jovem pergunta isso alguma vez.

— Por que não jogaram esse sistema fora?

Porque o sistema deixou de ser apenas código.

Ele virou história acumulada.

Uma franquia também.

Imagine tentar reconstruir décadas de personagens, acontecimentos, piadas internas, relações e regras simplesmente dizendo:

— Vamos começar do zero.

Você perde alguma coisa.

Por isso remakes são tão interessantes.

Eles precisam resolver um problema semelhante ao da modernização de legado:

quanto preservar e quanto transformar?


🎮 E então veio o anime

Para muita gente moderna, especialmente fora do Japão, o primeiro contato com Rance não aconteceu diante de um PC-98.

Aconteceu através da animação baseada em Rance 01.

E isso cria uma inversão histórica engraçada.

A pessoa encontra a animação e pensa:

— Isso virou jogo?

Não.

O caminho foi aproximadamente:

1989
JOGO ORIGINAL
     |
     |
     | décadas de franquia
     v
2013
REMAKE
RANCE 01
     |
     v
ADAPTAÇÃO ANIMADA

Ou seja, quando você encontra a animação está olhando para a camada mais recente de um stack cultural muito mais antigo.

É como conhecer CICS através de uma API REST e concluir que CICS deve ter sido inventado depois da Internet.

😂

Não exatamente.


⚠️ O elefante — gigantesco — dentro da dungeon

Não dá para discutir Rance seriamente fingindo que determinado aspecto não existe.

A franquia nasceu dentro do mercado adulto japonês.

E Rance possui comportamentos que, vistos pelos padrões atuais — e muitas vezes até dentro da própria narrativa — são extremamente problemáticos.

Isso precisa ser contextualizado, não romantizado.

Há uma diferença fundamental entre:

estudar uma obra culturalmente

e

aprovar moralmente tudo que existe nela.

Podemos estudar literatura medieval sem defender todas as práticas medievais.

Podemos estudar propaganda antiga sem concordar com ela.

Podemos estudar software inseguro sem recomendar:

PASSWORD = "1234"

😂

Rance é interessante justamente porque é também um artefato de uma determinada indústria, época e público.

Apagar essa parte seria apagar justamente aquilo que queremos compreender.


🕹️ A liberdade estranha dos computadores japoneses

Os PCs japoneses ofereciam espaço para experiências que os consoles frequentemente não permitiam da mesma maneira.

Consoles dependiam de fabricantes, licenciamento, distribuição física e políticas específicas.

O computador pessoal podia abrigar nichos.

E nichos são laboratórios culturais.

Visual novels cresceram ali.

Adventure games cresceram ali.

Eroges cresceram ali.

Experimentos narrativos cresceram ali.

Algumas dessas ideias posteriormente migrariam, seriam transformadas, suavizadas ou reaproveitadas em outros formatos.

Anime.

Mangá.

Light novel.

Jogos mainstream.

A cultura não respeita perfeitamente as fronteiras dos diretórios.

Ela faz:

COPY IDEA FROM NICHE
          TO MAINSTREAM.

Às vezes ninguém percebe de onde veio.


🌐 E então chegou a Internet

Aqui a história muda completamente.

Durante muito tempo, uma obra japonesa obscura podia permanecer praticamente invisível fora do Japão.

Depois vieram:

fóruns,

fan translations,

emulação,

wikis,

sites especializados,

YouTube,

Reddit,

Steam,

redes sociais.

De repente, o passado japonês começou a ficar acessível.

Uma pessoa em Itatiba pode estar tomando café em 2026 e perguntar:

— Que diabo é Rance 01?

Trinta minutos depois estamos discutindo PC-98, AliceSoft, história do RPG japonês, COBOL e genealogia do isekai.

Isso seria praticamente impossível em 1989.

E é exatamente por isso que amo a Internet quando ela funciona como deveria.

Ela transforma curiosidade em arqueologia.


🗿 Easter Egg Bellacosa #01 — 1989

Existe uma beleza quase poética nessa data.

Rance começou em 1989.

A própria AliceSoft, décadas depois, comemoraria explicitamente a longevidade da franquia, chegando a produzir material comemorativo de 35 anos.

Trinta e cinco anos.

No mundo da informática isso é praticamente:

ERA GEOLÓGICA.

Um software com 35 anos geralmente vem acompanhado de alguém dizendo:

— Não mexe nessa variável.

— Por quê?

— Ninguém sabe.

— Quem escreveu?

— Aposentou.

— Quando?

— 2007.

— Posso apagar?

— NÃO!

😂


🗿 Easter Egg Bellacosa #02 — legado não significa imóvel

Esse é outro erro comum.

Quando dizemos “legado”, muita gente entende:

velho e parado.

Mas sistemas legados frequentemente mudam o tempo inteiro.

Rance também mudou.

Plataformas mudaram.

Interface mudou.

Arte mudou.

Mecânicas mudaram.

O mundo cresceu.

O que permaneceu foi uma linha de continuidade.

Exatamente como sistemas corporativos.

Você pode ter um programa cujo ancestral foi escrito em 1978 e que hoje possui:

DB2,

MQ,

REST,

JSON,

Java,

z/OS Connect,

Git,

pipeline CI/CD.

Ele continua sendo legado.

Mas não está congelado em âmbar.


🧙 Easter Egg Bellacosa #03 — o verdadeiro feitiço era compatibilidade

Imagine tentar executar software de 1989 hoje.

Hardware mudou.

Sistema operacional mudou.

Codificação mudou.

Mídia mudou.

Drivers mudaram.

Resoluções mudaram.

Arquiteturas mudaram.

Mas a obra ainda existe.

Isso nos leva a uma pergunta maravilhosa:

quanto da nossa cultura digital atual conseguiremos executar daqui a cinquenta anos?

Essa pergunta é muito maior do que Rance.

É preservação digital.

Quem preservará:

jogos online?

MMORPGs desligados?

aplicativos mobile?

conteúdo dependente de servidores?

experiências baseadas em DRM?

software SaaS?

Talvez ironicamente um jogo distribuído num disco físico em 1989 tenha melhores chances arqueológicas do que determinado jogo online lançado em 2025.

Pense nisso.


☕ A máquina de café começa a ficar filosófica

Talvez seja isso que mais me fascina quando encontramos uma obra como Rance.

Você começa perguntando sobre um anime estranho.

Puxa um fio.

Descobre um jogo.

Puxa outro.

Descobre AliceSoft.

Outro.

PC-98.

Outro.

História dos computadores japoneses.

Outro.

Adventure games.

Outro.

RPGs.

Outro.

Visual novels.

Outro.

Light novels.

Outro.

Mushoku Tensei.

Outro.

Isekai.

Quando percebe, aquela pergunta aparentemente banal abriu uma porta para quase quarenta anos de história da cultura digital japonesa.

É por isso que nunca desprezo uma curiosidade.

Curiosidade é uma query.

Você nunca sabe quantas tabelas ela vai acabar acessando.


🧠 O passado não desaparece — ele vira dependência

Programadores entendem isso melhor do que ninguém.

Existe uma ideia moderna de que tecnologia evolui substituindo completamente aquilo que existia antes.

Na prática:

NOVO
 |
 +-- depende de ALGO ANTIGO
                  |
                  +-- depende de ALGO MAIS ANTIGO
                                   |
                                   +-- "NÃO TOQUE"

😂

Cultura funciona parecido.

O anime moderno possui dependências.

O isekai possui dependências.

A light novel possui dependências.

O JRPG possui dependências.

E algumas dessas dependências levam a lugares inesperados.

Como um computador NEC de 1989.


🚚 Talvez Truck-kun seja apenas uma API

Depois de toda essa viagem, comecei a desconfiar de uma coisa.

Truck-kun não transporta ninguém.

Ele simplesmente executa:

CALL 'ISEKAI'
 USING PROTAGONIST
       MEMORY
       CHEAT-SKILL
       TRAUMA.

RETURN-CODE = 00.

😂

Rance não precisava disso.

Ele já estava do outro lado.


☕ Último gole

Quando encontramos Rance 01 hoje, é tentador enxergá-lo apenas através da estética, do conteúdo adulto ou da animação posterior.

Mas quando recuamos alguns passos aparece algo muito mais interessante.

Encontramos uma franquia cuja origem remonta a 1989.

Encontramos a cultura dos computadores pessoais japoneses.

Encontramos PC-98, MSX, X68000 e FM Towns associados à história inicial da série.

Encontramos adventure games misturados com RPG.

Encontramos uma indústria adulta que funcionou também como laboratório narrativo e tecnológico.

Encontramos décadas de worldbuilding.

Encontramos um remake lançado em 2013 reconstruindo um jogo de 1989.

E, seguindo algumas arestas desse gigantesco grafo cultural, encontramos inclusive ecos reconhecidos em gerações posteriores de fantasia japonesa.

Não precisamos transformar Rance no “pai do isekai”.

Ele não é.

Também não precisamos fingir que os elementos problemáticos da franquia não existem.

Existem.

O que precisamos fazer é algo muito mais interessante:

colocá-lo na linha do tempo.

Porque quando fazemos isso percebemos que aquilo que parece estranho em 2026 pode ter sido parte de uma longa cadeia de experimentação que ajudou a formar o ecossistema no qual obras modernas nasceram.

E essa talvez seja uma das grandes lições da arqueologia digital.

Nunca olhe apenas para a interface.

Nunca olhe apenas para o programa.

Nunca olhe apenas para o anime.

Pergunte:

O que existia antes disso?

Depois siga as dependências.

Às vezes você encontrará um framework de 2018.

Às vezes encontrará Java.

Às vezes encontrará COBOL.

E às vezes...

...depois de atravessar 37 anos de dependências culturais...

você encontrará um NEC PC-98, uma AliceSoft ainda jovem e um aventureiro chamado Rance esperando alguém colocar o próximo disquete.

Na tela aparece:

READY.

> START ADVENTURE

LOADING...

PLEASE WAIT.

E lá do fundo da sala alguém pergunta:

— Bellacosa... isso tudo começou porque você resolveu assistir um anime?

Sim.

Era para ser cinco minutos.

Mas alguém deixou a porta da dungeon aberta.

☕😆

DISPLAY 'FIM DO ARTIGO'.

STOP RUN.



⚠️ P.S. — Antes de procurar Rance 01 achando que encontrou outro anime de fantasia...

Uma observação importante ficou propositalmente para depois do STOP RUN.

Se este artigo despertou sua curiosidade e você pretende procurar Rance 01: Hikari wo Motomete – The Animation, atenção:

não estamos falando de um anime convencional de fantasia com algumas cenas ecchi.

A adaptação animada de Rance 01 pertence ao mercado hentai, ou seja, é uma produção adulta com conteúdo sexual explícito. A existência desse material faz parte da história da franquia e do mercado japonês de jogos adultos do qual Rance surgiu, mas isso é bastante diferente de recomendar a animação como se fosse apenas mais um RPG transformado em anime.

Em outras palavras:

RANCE 01 — JOGO
      |
      +-- RPG
      +-- Adventure
      +-- fantasia
      +-- worldbuilding
      +-- conteúdo adulto
      |
      v
RANCE 01 — THE ANIMATION
      |
      +-- adaptação adulta explícita

Isso também ajuda a explicar algo que pode causar estranheza para quem encontra imagens ou vídeos da animação: a censura visual.

🇯🇵 Por que aparece aquela censura japonesa?

Não é defeito no vídeo.

Não é seu monitor CRT perdendo sincronismo.

E definitivamente não é:

IEC141I 013-18
CENSURA DATASET NOT FOUND

😆

O Japão possui uma história jurídica peculiar relacionada à representação pública de material sexual explícito. O famoso Artigo 175 do Código Penal japonês, cuja origem remonta ao início do século XX, estabelece restrições à distribuição de material considerado obsceno.

Com o desenvolvimento de mangás, filmes, jogos e animações adultos, a indústria japonesa desenvolveu diferentes mecanismos para adequar suas obras a essas restrições.

Daí surgiram aquelas censuras que se tornaram visualmente reconhecíveis até fora do Japão:

mosaicos, pixelização, barras, áreas ocultadas e outros recursos gráficos.

Existe aí uma ironia tecnológica maravilhosa.

O Japão ajudou a produzir algumas das tecnologias visuais mais avançadas do planeta...

...e simultaneamente transformou um punhado gigantesco de pixels em instrumento jurídico.

😂

🖥️ Do PC-98 ao mosaico

Isso também faz parte da arqueologia que estamos fazendo.

Quando estudamos jogos adultos japoneses antigos, encontramos uma interseção improvável entre:

TECNOLOGIA
     +
LEGISLAÇÃO
     +
CULTURA
     +
MERCADO
     +
LIMITAÇÕES GRÁFICAS

O resultado é uma estética que acabou se tornando característica de determinada produção japonesa.

O curioso é que aquilo que começou como mecanismo de censura acabou virando praticamente um símbolo visual reconhecido internacionalmente.

Você vê o mosaico e imediatamente pensa:

Japão.

É quase uma assinatura cultural involuntária.

⚠️ E Rance ainda acrescenta outra camada

Rance não foi concebido como exemplo de comportamento heroico.

Muito pelo contrário.

O personagem é deliberadamente egoísta, sexualmente obsessivo e moralmente problemático, e a franquia contém situações que podem ser bastante desconfortáveis quando analisadas pelos padrões contemporâneos.

Por isso existe uma diferença importante entre dizer:

“Rance é historicamente interessante.”

e dizer:

“Rance é moralmente admirável.”

A primeira afirmação pode render horas de discussão sobre história dos computadores japoneses, PC-98, AliceSoft, RPGs, visual novels, eroge e desenvolvimento da cultura otaku.

A segunda...

Bom...

o departamento de Compliance acabou de desligar nosso terminal.

😂

🏺 O interesse deste artigo é arqueológico

É justamente por isso que trouxe Rance para Um Café no Bellacosa Mainframe.

Não pela pornografia.

Mas porque, removendo essa primeira camada, encontramos um artefato curioso da história do software japonês.

Encontramos 1989.

Encontramos PC-98.

Encontramos AliceSoft.

Encontramos RPG.

Encontramos adventure games.

Encontramos décadas de continuidade narrativa.

Encontramos remakes.

Encontramos mudanças tecnológicas.

Encontramos influências atravessando gerações.

E encontramos uma oportunidade de entender como mercados que pareciam pequenos ou marginais também participaram da evolução dos jogos japoneses.

Estudar essa história não exige fingir que seu conteúdo adulto não existe.

Muito pelo contrário.

Contextualizá-lo corretamente faz parte da história.

☕ Portanto, fica o aviso da máquina de café

Se você chegou até aqui pensando:

“Vou procurar esse Rance 01. Deve ser parecido com Konosuba.”

NÃO EXECUTE ESSE JOB EM PRODUÇÃO SEM LER O MANUAL.

😆

Konosuba pode mandar Kazuma roubar uma calcinha e transformar tudo numa piada.

Rance vem de outra prateleira da indústria japonesa.

Uma prateleira marcada claramente:

***************************************
*                                     *
*          CONTEÚDO ADULTO             *
*                                     *
*   NÃO CONFUNDIR COM ANIME ECCHI      *
*                                     *
***************************************

E talvez essa seja a maneira mais interessante de terminar nossa escavação.

Podemos estudar uma obra sem precisar transformá-la em modelo.

Podemos reconhecer sua influência sem ignorar seus problemas.

Podemos analisar seu contexto sem apagar aquilo que hoje causa desconforto.

Porque arqueologia cultural funciona exatamente assim.

O arqueólogo não olha para um objeto antigo e pergunta apenas:

“Eu usaria isso hoje?”

Ele pergunta:

“O que este objeto me conta sobre as pessoas, a tecnologia e a sociedade que o produziram?”

E Rance conta muita coisa.

Sobre PCs japoneses.

Sobre videogames.

Sobre fantasia.

Sobre mercados adultos.

Sobre censura.

Sobre legislação.

Sobre evolução tecnológica.

E sobre como uma obra lançada quando muita gente ainda carregava software em disquetes conseguiu continuar sendo discutida quase quatro décadas depois.

Agora sim:

WARNING: ADULT CONTENT DETECTED

HISTORICAL CONTEXT ............ OK
PC-98 ARCHAEOLOGY ............. OK
CULTURAL ANALYSIS ............. OK
HENTAI RECOMMENDATION ......... NO

RETURN-CODE = 00

DISPLAY 'AGORA SIM, FIM DO ARTIGO'.

STOP RUN.

☕😆

segunda-feira, 12 de maio de 2014

💣🔥 POSSESSÃO EM PRODUÇÃO: QUANDO O ‘SISTEMA HUMANO’ RODA SEM FIREWALL — E O DEMÔNIO FAZ LOGIN ROOT 🔥💣

 

Bellacosa Mainframe explora a possessão espiritual

💣🔥 POSSESSÃO EM PRODUÇÃO: QUANDO O ‘SISTEMA HUMANO’ RODA SEM FIREWALL — E O DEMÔNIO FAZ LOGIN ROOT 🔥💣

Um dossiê Bellacosa Mainframe sobre livre-arbítrio, exploits espirituais e o bug mais antigo da humanidade


🖥️ INTRODUÇÃO — O INCIDENTE QUE TODO MUNDO JÁ OUVIU FALAR

No imaginário popular, o cenário é sempre o mesmo:

  • Um humano aparentemente normal
  • Um “processo externo” entra sem autenticação
  • Controle total assumido
  • Sistema comprometido

👉 Traduzindo pro nosso dialeto:

“O host humano foi invadido sem passar por RACF.”

Mas… será que é isso mesmo?


🔐 CAPÍTULO 1 — LIVRE-ARBÍTRIO NÃO É DESABILITADO (ELE É CONTORNADO)

No modelo clássico religioso (especialmente cristão), o humano tem:

  • livre-arbítrio ativo
  • controle sobre sua “instância espiritual”

Pensadores como Tomás de Aquino defendiam algo direto:

não existe takeover sem algum tipo de abertura

👉 Ou seja:
não é brute force
é engenharia social espiritual


💡 Analogia Bellacosa:

  • humano = sistema z/OS
  • consciência = RACF
  • demônio = usuário tentando escalar privilégio

O ataque não é:

LOGIN ROOT FORÇADO

É mais assim:

USER AUTORIZOU SEM PERCEBER

🧠 CAPÍTULO 2 — O VERDADEIRO EXPLOIT: A MENTE HUMANA

A psicologia moderna entra como um debugger nessa história:

  • dissociação
  • trauma
  • estados alterados
  • sugestão cultural

👉 O “invasor” pode não ser externo.

Pode ser:

um processo interno rodando fora do controle do scheduler consciente


🎌 E aqui o anime entra com força:

  • Em Naruto → Kurama não invade, ele coexiste e negocia
  • Em Jujutsu Kaisen → Sukuna só age quando há brecha
  • Em Tokyo Ghoul → o conflito é interno, não externo
  • Em Bleach → o Hollow nasce do próprio espírito

👉 Percebe o padrão?

O “demônio” raramente é só invasor.
Ele é amplificador do que já existe.


⚙️ CAPÍTULO 3 — POR QUE HUMANOS PARECEM FRÁGEIS?

Porque a narrativa foi construída assim.

Na cultura popular:

  • humano = sistema legado
  • demônio = exploit moderno

👉 Isso cria tensão.

Mas na visão mais profunda:

  • humanos têm consciência
  • capacidade simbólica
  • autoconhecimento

👉 Isso é absurdamente poderoso.

Só que…

é um sistema complexo — e sistemas complexos têm mais pontos de falha.


🌿 CAPÍTULO 4 — ERVAS, AMULETOS E REZAS = PATCHES DE PRODUÇÃO

Por que isso “funciona”?

Não é magia simplista.

É arquitetura simbólica:

  • reforça crença
  • reorganiza o estado mental
  • cria barreira psicológica
  • ativa foco e intenção

👉 Em linguagem Bellacosa:

não é o hardware… é o firmware da mente sendo reconfigurado


🎭 CAPÍTULO 5 — O TEATRO DO MEDO (E POR QUE ELE FUNCIONA)

Obras como The Exorcist venderam uma ideia:

  • invasão instantânea
  • perda total de controle
  • humano impotente

👉 Isso não é teologia.
Isso é roteiro otimizado para pânico.


🔥 CAPÍTULO 6 — O VERDADEIRO “ROOT ACCESS”

Se a gente junta tudo:

  • religião → fala em abertura
  • psicologia → fala em fragmentação
  • cultura pop → fala em invasão

O resultado real é mais interessante:

o “domínio” acontece quando o humano perde governança sobre si mesmo

Não é sobre demônios fortes.

É sobre:

  • identidade instável
  • consciência desconectada
  • falta de integração interna

🧠💣 CONCLUSÃO — O MAIOR SEGREDO DO SISTEMA

Aqui vai o insight estilo Bellacosa:

💥 O humano não é um sistema fraco
💥 Ele é um sistema mal compreendido

E o “demônio”?

Na maioria das narrativas (e até em muitos casos reais):

👉 não é administrador do sistema
👉 é apenas um processo oportunista


🚨 LOG FINAL

SYSTEM: HUMANO
STATUS: COMPLEXO
FALHA: AUTOCONHECIMENTO INSUFICIENTE
RISCO: ENGENHARIA SOCIAL INTERNA
CORREÇÃO: CONSCIÊNCIA + DISCIPLINA + SIGNIFICADO
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...