Translate

Mostrar mensagens com a etiqueta prioridades. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta prioridades. Mostrar todas as mensagens

sábado, 25 de setembro de 2021

Yak Shaving Rules: Quando um Programador COBOL Entrou na Matrix para Corrigir um Bug... e Quase Reinventou Todo o Sistema

 

Bellacosa Mainframe e a yak shaving rules

☕ Um Café no Bellacosa Mainframe

Yak Shaving Rules sem Mistérios

Quando um Programador COBOL Entrou na Matrix para Corrigir um Bug... e Quase Reinventou Todo o Sistema

"Você entrou na Matrix para resolver um problema. Mas antes decidiu atualizar o compilador, reorganizar os COPYBOOKs, trocar o editor, renomear variáveis, revisar o JCL... e esqueceu qual era o problema."


Introdução — Bem-vindo ao Labirinto da Matrix

A chuva verde de caracteres desce lentamente pelas telas.

Neo observa uma pequena mensagem piscando em vermelho.

ABEND S0C7

— Morpheus, encontramos o problema?

Morpheus responde calmamente:

— Ainda não.

Neo estranha.

— Mas acabamos de passar oito horas trabalhando.

Morpheus sorri.

— Sim.

Você atualizou o ambiente.

Padronizou os comentários.

Organizou as bibliotecas.

Criou um novo padrão de nomenclatura.

Instalou uma versão mais nova do editor.

Revisou o JCL.

Atualizou o Git.

Refatorou um programa que nem estava relacionado.

Criou documentação.

Mudou o tema do ISPF.

...

Mas o ABEND continua acontecendo.

Neo olha assustado.

— Então o que aconteceu?

O Oráculo responde:

"Você começou a aparar um iaque."

Assim nasce um dos conceitos mais curiosos da Engenharia de Software.

O famoso Yak Shaving.

Ele parece engraçado.

Mas custa milhões de dólares por ano em produtividade desperdiçada.


O que é Yak Shaving?

Yak Shaving significa:

Executar uma longa sequência de tarefas secundárias antes de finalmente resolver o problema original.

Você começa tentando resolver um problema simples.

No caminho encontra outro.

Depois outro.

Depois outro.

Quando percebe...

esqueceu completamente o motivo inicial.


Uma definição divertida

Imagine que alguém diga:

"Preciso cortar o cabelo."

Mas para cortar o cabelo precisa:

  • pegar o carro

  • abastecer

  • trocar o óleo

  • lavar o carro

  • calibrar pneus

  • renovar o seguro

  • comprar um GPS novo

  • instalar aplicativo

  • atualizar o celular

No final do dia...

o cabelo continua igual.

Isso é Yak Shaving.


A origem do termo

O nome surgiu na década de 1990.

Foi popularizado por Carlin Vieri e posteriormente difundido por MIT AI Lab e por programadores da comunidade Unix.

A inspiração veio de uma piada do humorista Ren & Stimpy.

A ideia era mostrar uma sequência absurda de tarefas onde uma ação aparentemente simples leva a dezenas de outras completamente inesperadas.

Desde então, Yak Shaving virou um termo clássico na Engenharia de Software.


Por que "Yak"?

Porque um iaque é um enorme bovino peludo do Himalaia.

A piada consiste justamente em imaginar alguém que precisa raspar um iaque antes de conseguir fazer outra tarefa completamente diferente.

É uma imagem absurda.

E exatamente por isso funciona tão bem.


Matrix explica perfeitamente

Imagine que Neo recebe uma missão.

Corrigir um programa COBOL responsável pelo cálculo do imposto.

Parece simples.

Mas então...


Missão 1

"Vou abrir o programa."

Antes...

precisa atualizar o editor.


Missão 2

Editor atualizado.

Agora percebe que o compilador está antigo.


Missão 3

Atualiza o compilador.

Agora alguns COPYBOOKs ficaram incompatíveis.


Missão 4

Atualiza COPYBOOKs.

Agora resolve reorganizar toda a biblioteca.


Missão 5

Aproveita para mudar o padrão dos nomes.


Missão 6

Já que mudou nomes...

resolve atualizar a documentação.


Missão 7

Agora cria diagramas.


Missão 8

Descobre que seria interessante migrar para GitFlow.


Missão 9

Aproveita para atualizar Jenkins.


Missão 10

O dia termina.

O bug original?

Continua lá.

O Agente Smith agradece.


Como nasce o Yak Shaving?

Geralmente começa assim.

"Já que estou aqui..."

Essa talvez seja a frase mais perigosa da Engenharia de Software.


"Já que estou neste programa..."

"Já que estou nesta rotina..."

"Já que estou compilando..."

"Já que estou mexendo..."

...

Horas depois...

o objetivo inicial desapareceu.


Exemplo COBOL

O usuário informou:

Cliente não consegue emitir boleto.

Problema simples.

Mas o desenvolvedor pensa:

"Vou aproveitar."

Então decide:

  • reorganizar WORKING-STORAGE

  • padronizar comentários

  • alinhar colunas

  • renomear variáveis

  • trocar GO TO por PERFORM

  • atualizar COPYBOOK

  • reorganizar PROCEDURE DIVISION

  • alterar indentação

Resultado?

O boleto continua sem funcionar.


O cérebro gosta disso

Curiosamente...

Yak Shaving é confortável.

Resolver tarefas pequenas produz sensação de progresso.

É muito mais agradável organizar nomes de variáveis do que investigar um erro complexo.

Nosso cérebro adora pequenas vitórias.

Por isso caímos nessa armadilha.


O problema real continua esperando

Enquanto você reorganiza detalhes...

o cliente continua parado.

O banco continua sem processar pagamentos.

O lote continua falhando.

O incidente continua aberto.


A diferença entre Yak Shaving e Refatoração

Muita gente confunde.

Não são iguais.

Refatoração

Melhora código relacionado ao problema.

Tem objetivo claro.

Entrega valor.


Yak Shaving

Executa dezenas de tarefas paralelas sem necessidade imediata.

Aumenta tempo.

Não resolve o problema principal.


Existe Yak Shaving bom?

Sim.

Às vezes.

Imagine.

Você precisa alterar um programa.

Antes percebe:

  • biblioteca corrompida

  • ambiente quebrado

  • compilador incompatível

Corrigir isso não é Yak Shaving.

É pré-requisito.

O segredo está na pergunta:

Essa atividade aproxima ou afasta da solução?


Matrix Reloaded

Na Matrix existe um personagem fascinante.

O Arquiteto.

Ele entende toda a estrutura.

Um bom arquiteto de software também evita Yak Shaving.

Porque consegue separar:

necessário

de

interessante.

Nem tudo que é interessante precisa ser feito agora.


Como identificar Yak Shaving?

Faça uma pergunta simples.

"Estou fazendo isso porque resolve o problema ou porque surgiu oportunidade?"

Se a resposta for:

"Já que estou aqui..."

acenda um alerta.


O Programador Padawan

Todo iniciante passa por isso.

Recebe um pequeno chamado.

Vai investigar.

Três horas depois está lendo documentação sobre VSAM RLS.

Cinco horas depois aprende DFSORT.

Sete horas depois instala uma nova fonte no VS Code.

No dia seguinte...

descobre que o problema era:

IF CPF = SPACES

O efeito dominó

Yak Shaving possui um comportamento interessante.

Cada nova tarefa gera outra.

Por exemplo.

Corrigir documentação.

Descobre padrão antigo.

Atualiza modelo.

Percebe que Wiki está desorganizada.

Resolve reorganizar Wiki.

Atualiza links.

Cria templates.

Muda identidade visual.

...

O problema inicial desapareceu.


Os Agentes Smith adoram Yak Shaving

Na Matrix, Smith cresce distraindo Neo.

No desenvolvimento acontece igual.

Quanto mais tarefas paralelas surgem...

menos energia sobra para o problema verdadeiro.

Smith não precisa impedir você.

Basta manter você ocupado.


Gestão de Projetos

Em projetos grandes isso custa caro.

Imagine uma Sprint de duas semanas.

Uma tarefa estimada em:

8 horas.

Após Yak Shaving.

Consome:

32 horas.

Ninguém entende por quê.

Na verdade...

o desenvolvedor trabalhou bastante.

Só trabalhou nas coisas erradas.


Como gestores combatem isso?

Scrum Masters fazem perguntas importantes.

Qual é o objetivo?

Essa atividade agrega valor?

Está no escopo?

Quem pediu?

É prioridade?

Pode esperar?

Essas perguntas quebram o ciclo.


Técnicas para evitar Yak Shaving

Defina objetivo claro

Antes de abrir o editor escreva:

"Hoje vou corrigir o cálculo do IOF."

Nada além disso.


Use lista de estacionamento

Encontrou outra melhoria?

Anote.

Não faça agora.


Time Boxing

Reserve tempo.

Exemplo:

90 minutos.

Depois reavalie.


Trabalhe por prioridade

Cliente primeiro.

Curiosidade depois.


Faça pequenas entregas

Entregas frequentes diminuem distrações.


Atenção!

Existe uma diferença enorme entre:

Melhorar

e

Perfeccionismo.

Perfeccionismo muitas vezes é Yak Shaving disfarçado.


Os perigos

Atrasos

Cronograma explode.


Retrabalho

Mudanças desnecessárias geram novos bugs.


Escopo infinito

Projeto nunca termina.


Burnout

Equipe trabalha muito.

Entrega pouco.


Perda de foco

Objetivo desaparece.


Um exemplo clássico no Mainframe

Chamado:

Alterar mensagem do CICS.

Durante a alteração:

Atualiza BMS.

Atualiza mapa.

Padroniza cores.

Renomeia campos.

Refatora tratamento.

Atualiza transações.

Altera HELP.

Reorganiza COPYBOOK.

Atualiza manual.

Muda nomenclatura.

Novo teste.

Novo Build.

Nova homologação.

Duas semanas depois...

A mensagem ainda não mudou.


Como o Oráculo resolveria?

Ela perguntaria apenas:

"O que realmente precisa acontecer?"

Essa pergunta elimina metade do Yak Shaving.


Aplicabilidade

Conhecer Yak Shaving ajuda em:

  • COBOL

  • CICS

  • Db2

  • DevOps

  • Cloud

  • IA

  • Engenharia de Dados

  • Projetos Ágeis

  • Infraestrutura

  • Segurança

Na verdade...

qualquer área técnica sofre com isso.


Curiosidades

Grandes empresas treinam desenvolvedores para reconhecer Yak Shaving.

Google possui diversas palestras internas sobre foco.

Microsoft fala sobre "Task Switching".

IBM enfatiza planejamento incremental.

Todas estão combatendo exatamente o mesmo problema.


O Checklist Anti-Yak

Antes de começar pergunte:

✅ Isso resolve o problema principal?

✅ O cliente percebe valor?

✅ Está dentro da Sprint?

✅ É realmente necessário agora?

✅ Posso anotar para depois?

Se respondeu "não" para a maioria...

provavelmente um iaque está esperando por você.


O Ensinamento de Morpheus

Morpheus entrega a Neo uma última mensagem.

"A Matrix não vence apenas pela força.
Ela vence pela distração."

Na Engenharia de Software acontece exatamente igual.

Poucos projetos fracassam porque seus desenvolvedores são incompetentes.

Muitos fracassam porque perderam o foco.


Lições para um Programador COBOL Padawan

Ao trabalhar em um sistema legado, é comum encontrar dezenas de oportunidades de melhoria. Um COPYBOOK poderia ser reorganizado, uma variável poderia ter um nome melhor, um programa poderia ser dividido em módulos menores, um JCL poderia ser simplificado. Tudo isso tem valor — mas nem tudo tem prioridade.

O verdadeiro profissional aprende a distinguir entre o trabalho importante e o trabalho interessante. Resolver o incidente que impede milhares de clientes de realizar uma transação é mais importante do que reorganizar comentários em um programa que funciona perfeitamente. As melhorias devem ser registradas, planejadas e executadas no momento adequado, não durante uma correção crítica.


Conclusão — Saindo da Matrix

No final de sua jornada, Neo compreende que a Matrix não era apenas um sistema de controle, mas também um sistema de distrações. Na Engenharia de Software, o Yak Shaving desempenha exatamente esse papel: cria uma sequência aparentemente lógica de tarefas secundárias que afastam a equipe do objetivo principal.

Para um Programador COBOL, especialmente em ambientes IBM Z onde cada alteração pode impactar processos críticos de bancos, seguradoras ou governos, manter o foco é uma habilidade tão importante quanto dominar a linguagem. Antes de iniciar qualquer atividade, pergunte a si mesmo:

  • Isso resolve o problema do cliente?

  • Isso agrega valor agora?

  • Estou caminhando em direção à solução ou apenas aparando um iaque?

Se a resposta indicar que você está entrando em um labirinto de tarefas paralelas, faça como Neo ao enxergar o código da Matrix: pare, respire, volte ao objetivo original e siga pelo caminho mais direto. Afinal, os melhores engenheiros não são aqueles que fazem mais coisas, mas aqueles que resolvem as coisas certas, no momento certo, com a menor complexidade possível. Esse é o verdadeiro caminho para escapar da Matrix do Yak Shaving e construir software que realmente faz diferença.

sábado, 14 de agosto de 2021

Bike Shedding Rules: Quando um Programador COBOL Descobriu que a Matrix Fazia Todos Discutirem a Cor da Bicicleta Enquanto a Usina Estava Prestes a Explodir

 

Bellacosa Mainframe e a bike shedding rules

☕ Um Café no Bellacosa Mainframe

Bike Shedding Rules sem Mistérios

Quando um Programador COBOL Descobriu que a Matrix Fazia Todos Discutirem a Cor da Bicicleta Enquanto a Usina Estava Prestes a Explodir

"A Matrix não precisa impedir você de resolver o problema. Basta convencer todos a discutir o problema errado."


Introdução — A Reunião Dentro da Matrix

Neo entra em uma enorme sala de reuniões.

Na parede existe um painel gigantesco.

No centro aparece um alerta crítico.

⚠️ Sistema Bancário Nacional
Fechamento Noturno em Risco

O problema é gravíssimo.

O processamento pode falhar.

Milhões de transações dependem daquela execução.

Neo pergunta:

— Quem está cuidando disso?

Morpheus responde.

— Eles.

Neo olha para a sala.

Os analistas discutem apaixonadamente.

Mas não sobre o processamento.

Não sobre o Db2.

Não sobre o COBOL.

Nem sobre o CICS.

Eles discutem:

  • a cor dos gráficos

  • o nome da nova aplicação

  • se o botão deveria ser azul ou verde

  • o tamanho da fonte

  • se o README usa Markdown ou AsciiDoc

  • qual editor é melhor

  • se comentários devem começar com "", ">", ou "*> "

Enquanto isso...

o Job continua falhando.

A Matrix sorri.

O Agente Smith também.

Você acaba de presenciar um clássico caso de Bike Shedding.


O que é Bike Shedding?

Bike Shedding é um fenômeno onde pessoas gastam enorme quantidade de tempo discutindo assuntos simples e pouco importantes, enquanto ignoram questões realmente críticas.

Em outras palavras:

Quanto mais simples o assunto, mais pessoas opinam. Quanto mais complexo, menos pessoas participam.

É um comportamento psicológico extremamente comum.

E perigosamente frequente em projetos de software.


A origem do termo

O conceito nasceu em 1957.

Foi apresentado pelo historiador e cientista britânico Cyril Northcote Parkinson.

No livro:

Parkinson's Law

Ele descreve uma situação fictícia.

Imagine uma comissão aprovando três projetos.

Primeiro

Construção de um reator nuclear.

Custo:

Bilhões.

Ninguém entende engenharia nuclear.

Resultado?

Aprovado em cinco minutos.


Segundo

Construção de um laboratório.

Pouca discussão.


Terceiro

Construção de um bicicletário.

Valor pequeno.

Todo mundo entende bicicletas.

Resultado?

Horas debatendo:

  • cor

  • localização

  • tamanho

  • telhado

  • pintura

O bicicletário consumiu mais tempo que a usina nuclear.

Assim nasceu:

Bike Shedding


Matrix explica perfeitamente

A Matrix vive desviando atenção.

Não precisa esconder a verdade.

Basta oferecer distrações.

Em projetos acontece igual.

Enquanto a arquitetura inteira desmorona...

todos discutem:

"Essa variável deveria chamar CLIENTE ou CLIENT?"


O paradoxo do conhecimento

Existe uma explicação psicológica interessante.

As pessoas evitam opinar sobre assuntos que não dominam.

Mas adoram opinar sobre aquilo que parece simples.

Por isso:

Arquitetura distribuída?

Silêncio.

Nome do programa?

Todo mundo vira especialista.


O Programador COBOL Padawan

Imagine.

Você participa da primeira reunião.

Tema oficial:

Modernização do Core Bancário.

Você imagina discussões sobre:

  • CICS

  • Db2

  • APIs

  • z/OS Connect

  • MQ

  • segurança

  • performance

Mas a reunião inteira é consumida por:

"O novo padrão de comentários terá três ou quatro traços?"


Exemplo COBOL

Existe um programa.

PROGRAM-ID. FATUR001.

A equipe precisa alterar:

Uma regra tributária nacional.

Impacto:

Milhões de clientes.

Mas a reunião debate durante uma hora:

FATUR001

ou

FATURA01

ou

FAT-001

ou

BILL001

A regra tributária?

Ainda ninguém analisou.


Como nasce o Bike Shedding?

Normalmente começa assim.

Alguém apresenta um assunto complexo.

O grupo sente dificuldade.

Então alguém muda para um detalhe simples.

Exemplo.

"Precisamos definir a arquitetura."

Silêncio.

Então alguém pergunta.

"A propósito...

qual será a cor do dashboard?"

Pronto.

Uma hora desaparece.


O efeito psicológico

Nosso cérebro gosta de participar.

Quando o assunto parece fácil...

todos querem contribuir.

Isso gera sensação de pertencimento.

Mas também desperdiça tempo.


Matrix Reloaded

Imagine Neo diante do Arquiteto.

O Arquiteto explica uma estrutura extremamente complexa.

Neo tenta entender.

Então alguém interrompe.

"Gostei desse terno branco.

Onde comprou?"

É exatamente isso que acontece nas empresas.


O Agente Smith ama Bike Shedding

Porque ele sabe:

Enquanto vocês discutem detalhes...

ninguém resolve o problema verdadeiro.


O impacto em projetos

Bike Shedding provoca:

  • reuniões intermináveis

  • atrasos

  • decisões lentas

  • perda de foco

  • desgaste da equipe

E o pior.

Dá sensação de produtividade.

Todos participaram.

Mas nada aconteceu.


Um exemplo no Mainframe

Projeto:

Migrar milhares de programas COBOL para Enterprise COBOL 6.5.

Questões realmente importantes:

  • compatibilidade

  • desempenho

  • testes

  • NUMPROC

  • TRUNC

  • ARCH

  • OPT

  • SSRANGE

  • RENT

Mas a reunião discute:

"O template do PowerPoint ficará azul IBM ou azul escuro?"


Outro exemplo

Projeto:

Criar API PIX.

Discussão:

REST.

OAuth.

TLS.

MQ.

CICS.

JSON.

Mas metade da Sprint foi consumida decidindo:

Qual será o ícone da documentação.


Como reconhecer Bike Shedding?

Faça uma pergunta simples.

"O tempo gasto discutindo isso é proporcional ao impacto?"

Se não...

provavelmente existe Bike Shedding.


Os sintomas

Reuniões longas.

Decisões pequenas.

Grandes decisões adiadas.

Muito debate.

Pouca entrega.


O custo invisível

Imagine.

15 pessoas.

Reunião de duas horas.

Discutindo:

Nome da aplicação.

São:

30 horas de trabalho.

Sem produzir uma linha de código.


O Programador Sênior

Os profissionais mais experientes normalmente fazem uma pergunta.

"Isso impede a entrega?"

Se não impede...

seguem adiante.


Matrix e a Escolha

Morpheus oferece duas pílulas.

A azul.

Discutir detalhes infinitamente.

A vermelha.

Resolver o problema.

Toda equipe escolhe diariamente.


Como evitar Bike Shedding?

Definir objetivo da reunião

Qual decisão precisa sair daqui?


Time Box

15 minutos.

Acabou.

Decide.


Priorizar impacto

Quanto maior o impacto...

mais atenção.


Nomear um facilitador

Alguém precisa trazer a conversa de volta.


Criar Parking Lot

Assuntos paralelos.

Anotados.

Resolvidos depois.


O papel do Scrum Master

Excelente Scrum Masters interrompem gentilmente.

"Esse assunto é importante.

Mas não agora."

Essa frase economiza semanas.


O COBOL ensina foco

Programadores COBOL antigos possuem uma característica interessante.

Eles perguntam:

"O que está quebrado?"

Não:

"O que poderia ficar bonito?"

Primeiro estabilidade.

Depois estética.


Atenção!

Existe diferença entre:

Detalhe importante

e

Detalhe pequeno.

Segurança pode parecer detalhe.

Não é.

Performance pode parecer detalhe.

Não é.

Mas discutir durante quarenta minutos:

ordem alfabética dos COPYBOOKs...

provavelmente é.


Os riscos

Escopo cresce


Projeto atrasa


Equipe desmotiva


Clientes esperam


Arquitetura piora

Porque ninguém teve tempo para ela.


Curiosidade

Google.

IBM.

Microsoft.

Amazon.

Todas treinam líderes para reduzir Bike Shedding.

Algumas utilizam:

  • Decision Records

  • RFCs

  • ADR (Architecture Decision Records)

Justamente para evitar discussões infinitas.


Um exemplo engraçado

Chamado:

"Erro no cálculo do IR."

Reunião.

Primeira hora.

Escolha do nome da branch.

Segunda hora.

Cor do dashboard.

Terceira hora.

Modelo do documento.

Quarta hora.

Finalmente alguém pergunta.

"O erro ainda existe?"

Sim.


O Oráculo explica

O Oráculo olha para Neo.

E pergunta.

"O que realmente importa?"

Essa pergunta encerra metade das reuniões inúteis do mundo.


Aplicabilidade

Bike Shedding aparece em:

  • Desenvolvimento

  • Infraestrutura

  • Cloud

  • Segurança

  • Banco de Dados

  • Mainframe

  • DevOps

  • IA

  • Projetos Ágeis

  • Gestão

É praticamente universal.


Boas práticas

Priorize valor

Cliente antes.

Estética depois.


Decisões reversíveis

Se puder mudar depois...

não desperdice horas.


Documente rapidamente

Decidiu.

Registre.

Siga em frente.


Use especialistas

Nem toda decisão precisa de vinte pessoas.


Faça perguntas

"Qual impacto?"

"Qual risco?"

"Qual benefício?"


Erros comuns

Querer consenso absoluto.

Confundir democracia com eficiência.

Dar o mesmo peso para toda decisão.

Ignorar prioridade.

Não encerrar discussões.


O ensinamento para o Programador COBOL Padawan

Você entrará em muitas reuniões.

Algumas serão fundamentais.

Outras parecerão infinitas.

Aprenda a distinguir.

Sempre pergunte:

"Essa conversa ajuda o cliente?"

Se não.

Talvez todos estejam apenas pintando o bicicletário.


Curiosidades adicionais

O conceito de Bike Shedding inspirou diversas práticas modernas de gestão:

  • Regra dos Dois Minutos para Decisões Simples: se a decisão é barata e reversível, decida rapidamente.

  • ADR (Architecture Decision Records): registrar decisões arquiteturais evita rediscussões constantes.

  • Disagree and Commit: popularizado pela Amazon, incentiva que, após uma decisão ser tomada, a equipe siga em frente mesmo sem consenso absoluto.

  • Impacto × Esforço: muitas organizações usam matrizes para concentrar energia nas decisões que realmente afetam o negócio.


Matrix Revela a Verdade

No final da trilogia, Neo compreende que o maior poder da Matrix nunca foi controlar máquinas.

Foi controlar a atenção das pessoas.

Na Engenharia de Software acontece exatamente o mesmo.

Projetos raramente fracassam porque ninguém sabia programar COBOL.

Eles fracassam porque energia, tempo e inteligência foram consumidos discutindo assuntos periféricos enquanto os problemas críticos permaneceram intocados.

Cada minuto debatendo a cor de um botão quando uma arquitetura precisa ser definida é como permitir que mais um Agente Smith se multiplique dentro da Matrix.


Conclusão — Não Pinte o Bicicletário Enquanto Zion Está Sob Ataque

Imagine que Zion esteja prestes a ser invadida.

As sentinelas aproximam-se.

O núcleo de energia está instável.

As comunicações falham.

Nesse cenário, ninguém pararia para discutir a cor da pintura da garagem das naves.

No entanto, em projetos de software isso acontece todos os dias.

Em ambientes IBM Z, onde aplicações COBOL movimentam bilhões de reais diariamente, o foco deve estar nas decisões que garantem disponibilidade, segurança, desempenho, confiabilidade e continuidade do negócio. Questões cosméticas têm seu lugar, mas não podem competir com decisões arquiteturais e operacionais críticas.

O Programador COBOL Padawan que deseja evoluir para um verdadeiro Arquiteto da Frota Estelar precisa desenvolver uma habilidade rara: distinguir o importante do apenas interessante. Antes de entrar em qualquer discussão, pergunte:

  • Isso reduz riscos para o negócio?

  • Isso melhora a qualidade do software?

  • Isso acelera a entrega de valor?

  • Ou estamos apenas discutindo a cor do bicicletário?

Porque, no universo Bellacosa Mainframe, existe uma regra que vale tanto para Zion quanto para um CPD bancário:

"Enquanto você debate detalhes sem importância, o verdadeiro problema continua executando em produção."

E essa talvez seja a maior ilusão criada pela Matrix.