 |
| Bellacosa Mainframe e o fator onibus rules em engenharia de software |
☕ Um Café no Bellacosa Mainframe
O Fator Ônibus Rules sem Mistérios
O Dia em que um Programador COBOL Descobriu que o Maior Risco do Mainframe Não Era um ABEND... Era uma Pessoa Só
"Computadores não guardam conhecimento. Pessoas guardam. O problema começa quando apenas uma pessoa sabe como tudo funciona."
Introdução — O Incidente na USS Enterprise
Imagine que a USS Enterprise esteja explorando um setor desconhecido da galáxia.
O Capitão Kirk está em uma missão diplomática.
Spock foi capturado pelos romulanos.
Scotty está preso na casa de máquinas tentando impedir uma explosão no núcleo de dobra.
McCoy está operando um tripulante.
Sulu está pilotando uma nave auxiliar.
Chekov perdeu comunicação.
Quem sabe operar toda a Enterprise?
Se apenas Scotty conhece o funcionamento do motor de dobra...
...a missão inteira depende dele.
No desenvolvimento de software acontece exatamente a mesma coisa.
Existe um conceito bastante conhecido na Engenharia de Software chamado Bus Factor (Fator Ônibus).
É uma métrica extremamente simples.
E extremamente assustadora.
O que é o Bus Factor?
Bus Factor mede:
Quantas pessoas podem deixar um projeto antes que ele deixe de funcionar.
Ou, na definição clássica:
Quantas pessoas precisariam ser atropeladas por um ônibus para que o projeto ficasse inviável.
Apesar do nome parecer humor negro, o objetivo nunca foi falar de acidentes.
Hoje muitas empresas preferem nomes como:
Lottery Factor
Truck Factor
Beer Truck Factor
Departure Factor
A ideia é a mesma.
Se apenas uma pessoa conhece todo o sistema...
Bus Factor = 1
Se cinco pessoas dominam tudo...
Bus Factor = 5
Quanto maior o número...
mais saudável é o projeto.
A origem do termo
O conceito apareceu informalmente nos anos 1990 em equipes de desenvolvimento.
Depois foi bastante difundido por comunidades Open Source.
Grandes projetos como:
Linux
Apache
PostgreSQL
Kubernetes
passaram a discutir continuamente como aumentar seu Bus Factor.
Hoje empresas como Google, Microsoft, IBM, Amazon e Meta utilizam práticas justamente para evitar esse risco.
Por que isso acontece?
Porque conhecimento técnico é caro.
E conhecimento acumulado durante anos é mais caro ainda.
Imagine um sistema bancário COBOL criado em 1987.
Foram feitas:
milhares de correções
centenas de integrações
dezenas de migrações
Mas apenas João conhece:
o motivo daquele IF estranho
porque existe aquele PERFORM GO TO
porque aquele arquivo VSAM não pode ser reorganizado na sexta-feira
Sem João...
ninguém entende.
O verdadeiro patrimônio não é o código
Muitos pensam:
"O código está no Git."
Não.
O código é apenas uma fotografia.
O conhecimento está na cabeça das pessoas.
Por exemplo.
Imagine este trecho:
IF CODIGO = 98
MOVE "N" TO PROCESSAR
END-IF
Todo mundo consegue ler.
Mas somente um programador sabe que:
"98 significa agência incorporada antes da fusão de 1999."
Isso nunca foi documentado.
O Bus Factor no Mainframe
Mainframe possui uma característica curiosa.
Sistemas vivem por décadas.
Enquanto aplicações Web costumam durar poucos anos...
há programas COBOL executando desde os anos 80.
Isso cria um fenômeno interessante.
Os programadores mudam.
O sistema permanece.
Quem sobrevive?
O conhecimento.
O Programador Lendário
Toda empresa possui um.
Normalmente conhecido por frases como:
"Pergunta para o Carlos."
ou
"Só a Maria sabe."
ou
"Não mexe nisso."
ou
"Esse módulo é do Roberto."
Quando alguém fala isso...
o Bus Factor acabou de aparecer.
Um caso clássico
Imagine um programa COBOL de 250 mil linhas.
Existe um JOB chamado:
PGM=FECHAMES
Todos sabem executá-lo.
Ninguém sabe como funciona.
Quando aparece erro...
esperam José voltar das férias.
Isso significa:
Bus Factor = 1
Como identificar um Bus Factor baixo?
Existem sinais muito claros.
Sempre chamam a mesma pessoa
"Fulano resolve."
Isso é risco.
Férias geram pânico
A equipe evita liberar férias.
Outro alerta.
Ninguém revisa aquele código
Porque ninguém entende.
Documentação inexistente
Tudo está "na memória".
Medo de alterar
Frases como:
"Melhor não mexer."
indicam conhecimento concentrado.
O impacto nos projetos
Um Bus Factor baixo provoca:
atrasos
retrabalho
bugs
decisões lentas
dependência
burnout
E principalmente:
medo.
Burnout técnico
O especialista nunca descansa.
Nunca tira férias.
Nunca muda de área.
Nunca cresce.
Porque virou gargalo.
Ele deixa de ser desenvolvedor.
Passa a ser suporte permanente.
O paradoxo
Muitos profissionais acreditam:
"Quanto menos gente souber, mais indispensável eu fico."
Na realidade acontece o contrário.
Empresas modernas promovem quem compartilha conhecimento.
Porque líderes multiplicam.
Guardiões escondem.
O Bus Factor no COBOL
Imagine um sistema composto por:
800 programas COBOL
120 CICS
300 JCL
90 PROC
60 COPYBOOK
15 VSAM
120 tabelas DB2
Apenas um analista conhece:
arquitetura
fluxo
dependências
Esse sistema possui Bus Factor baixíssimo.
Como aumentar o Bus Factor?
1. Documentação viva
Não basta Word esquecido.
Documentação precisa acompanhar o código.
2. Code Review
Todo código passa por outra pessoa.
Assim o conhecimento circula.
3. Pair Programming
Duas pessoas desenvolvendo juntas.
Muito comum em Extreme Programming.
4. Rotação de equipes
Hoje você mantém cobrança.
Amanhã cartões.
Depois investimentos.
Conhecimento distribuído.
5. Treinamentos internos
Mini workshops.
Lightning Talks.
Brown Bag Sessions.
Lunch & Learn.
6. Diagramas
Fluxos ajudam mais do que textos enormes.
7. Wiki
Confluence.
GitHub Wiki.
Markdown.
Obsidian.
Qualquer coisa melhor que memória humana.
8. Comentários úteis
Não explique COBOL.
Explique regra de negócio.
Ruim:
MOVE X TO Y
Bom:
* Conta especial criada após Resolução BACEN 2451
O papel dos COPYBOOKS
No Mainframe, COPYBOOKS também espalham conhecimento.
Padronizam:
layouts
mensagens
estruturas
contratos
Isso reduz dependências.
A importância dos testes
Testes também documentam.
Um bom teste responde:
"O que esse programa deveria fazer?"
Integração com IA
Hoje IA ajuda muito.
Ela pode:
explicar COBOL
gerar documentação
criar diagramas
resumir programas
Mas atenção.
Ela aprende com o código disponível.
Se o conhecimento nunca foi registrado...
nem a IA consegue descobrir.
Bus Factor e sucessão
Toda empresa deveria perguntar:
"Se João sair amanhã, conseguimos continuar?"
Se a resposta for "não"...
o problema já existe.
Curiosidade
Algumas empresas medem oficialmente:
percentual de conhecimento compartilhado
quantidade de revisores
cobertura de documentação
Tudo isso influencia o Bus Factor.
Um exemplo divertido
Imagine o motor de dobra da Enterprise.
Scotty conhece:
manutenção
peças
ajustes
gambiarra klingon
Se Scotty aposentar...
a nave para.
Kirk então decide:
treinar Geordi (sim, ele ainda nem nasceu nesta linha temporal!)
criar manuais
registrar procedimentos
Bus Factor aumenta.
Erros mais comuns
Heroísmo
"O sistema depende de mim."
Não deveria.
Falta de documentação
Erro clássico.
Não ensinar
Conhecimento escondido envelhece.
Medo de perder espaço
Na prática ocorre o contrário.
Quem ensina cresce.
Sistemas sem arquitetura
Tudo funciona.
Ninguém entende.
O que um Padawan COBOL deve aprender?
Nunca seja apenas executor.
Entenda:
negócio
arquitetura
fluxo
integração
histórico
Quanto mais contexto...
mais valor você gera.
Outros termos curiosos da Engenharia de Software
O Bus Factor faz parte de uma enorme coleção de conceitos curiosos usados por arquitetos de software.
1. Technical Debt (Dívida Técnica)
Atalhos tomados hoje que gerarão custo no futuro.
2. Yak Shaving
Resolver dezenas de problemas irrelevantes antes do verdadeiro.
3. Bike Shedding
Horas discutindo detalhes pequenos.
Exemplo:
"A cor do botão."
Enquanto ninguém fala da arquitetura.
4. Golden Hammer
Usar sempre a mesma tecnologia.
"Para tudo usamos Java."
Mesmo quando não faz sentido.
5. Cargo Cult Programming
Copiar código sem entender.
Muito comum na internet.
6. Spaghetti Code
Código totalmente desorganizado.
7. Lasagna Code
Camadas demais.
Tudo depende de tudo.
8. Big Ball of Mud
Sistema gigantesco sem arquitetura definida.
Muito comum em sistemas antigos.
9. God Object
Objeto que faz absolutamente tudo.
10. Lava Flow
Código antigo que ninguém remove.
Porque ninguém sabe se ainda é usado.
11. Boiling Frog
Problemas pequenos acumulam lentamente.
Quando percebem...
o sistema virou caos.
12. Death March Project
Projeto impossível desde o início.
Prazo irreal.
Equipe pequena.
Escopo gigante.
13. Brooks's Law
Do clássico The Mythical Man-Month:
"Adicionar pessoas a um projeto atrasado o atrasará ainda mais."
Porque novos membros precisam aprender.
14. Conway's Law
O software reflete a estrutura organizacional.
Departamentos separados criam sistemas separados.
15. Murphy's Law
Tudo que pode falhar...
falhará.
Por isso existem testes.
16. KISS
Keep It Simple.
Soluções simples sobrevivem mais.
17. YAGNI
You Aren't Gonna Need It.
Não implemente funcionalidades imaginárias.
18. DRY
Don't Repeat Yourself.
Evite duplicação.
19. SOLID
Cinco princípios para software sustentável.
20. Boy Scout Rule
"Deixe o código um pouco melhor do que encontrou."
Uma pequena melhoria por vez transforma um sistema inteiro ao longo dos anos.
O grande ensinamento
O verdadeiro objetivo do Bus Factor não é medir acidentes.
É medir resiliência organizacional.
Em um ambiente Mainframe, onde sistemas podem sobreviver por 30, 40 ou até 50 anos, o ativo mais valioso não é o servidor IBM Z, nem o Db2, nem o CICS, nem o código COBOL. É o conhecimento coletivo da equipe.
Quando apenas uma pessoa conhece um módulo crítico, cria-se um ponto único de falha tão perigoso quanto um disco sem redundância ou um banco de dados sem backup. Por outro lado, quando o conhecimento é compartilhado por meio de documentação, revisões de código, mentorias, treinamentos, programação em pares e rotação de responsabilidades, o sistema torna-se mais robusto e a equipe evolui em conjunto.
Para um Programador COBOL Padawan, a maior lição é esta: não aspire ser insubstituível; aspire ser inesquecível. O profissional que ensina, documenta, orienta e forma novos especialistas deixa um legado muito maior do que aquele que guarda segredos técnicos. Assim como na Frota Estelar, uma nave não depende de um único oficial para cumprir sua missão. Ela depende de uma tripulação preparada, colaborativa e capaz de assumir o comando quando necessário.
No fim das contas, o melhor indicador de maturidade de uma equipe não é quantas pessoas sabem tudo, mas quantas conseguem continuar navegando com segurança quando qualquer membro precisa se afastar. Esse é o verdadeiro espírito do Bus Factor: transformar conhecimento individual em patrimônio coletivo, garantindo que a missão continue, independentemente de quem esteja na ponte de comando.
