Translate

Mostrar mensagens com a etiqueta atrasos. Mostrar todas as mensagens
Mostrar mensagens com a etiqueta atrasos. 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.

domingo, 27 de setembro de 2020

Brooks's Law Rules: Quando um Programador COBOL Descobriu que Colocar Mais Pessoas na Matrix Não Fazia o Tempo Andar Mais Devagar

 

Bellacosa Mainframe e a brooks law rules

☕ Um Café no Bellacosa Mainframe

Brooks's Law Rules sem Mistérios

Quando um Programador COBOL Descobriu que Colocar Mais Pessoas na Matrix Não Fazia o Tempo Andar Mais Devagar

"Nove mulheres não fazem um bebê nascer em um mês. Da mesma forma, vinte programadores não entregam um projeto de seis meses em apenas duas semanas." — Inspirado em Frederick P. Brooks Jr.


Prólogo — A Reunião de Emergência na Nebuchadnezzar

A situação era crítica.

Faltavam apenas vinte dias para entregar a nova versão da Matrix.

Neo.

Trinity.

Morpheus.

Link.

Tank.

Todos trabalhavam sem parar.

Mesmo assim.

O cronograma continuava atrasado.

A reunião começou.

O Arquiteto entrou na sala.

Projetou um gráfico.

Prazo: 20 dias

Trabalho restante: 90 dias

Silêncio.

Então um executivo da Matrix levantou a mão.

Sorriu confiante.

— Tenho a solução.

Neo perguntou.

— Qual?

O executivo respondeu:

— Vamos contratar cinquenta programadores.

Todos ficaram olhando.

Morpheus fechou os olhos.

O Oráculo deu um leve sorriso.

Neo perguntou:

— Eles conhecem COBOL?

— Não.

— Conhecem CICS?

— Não.

— Conhecem Db2?

— Também não.

— Conhecem o negócio?

— Ainda não.

— Conhecem a arquitetura?

— Nunca viram.

Neo respirou profundamente.

O Oráculo então falou.

"Vocês não contrataram cinquenta programadores. Contrataram cinquenta aprendizes que precisarão aprender com aqueles que já estão atrasados."

Naquele instante, Neo compreendeu a Lei de Brooks.


O que é a Brooks's Law?

A Brooks's Law afirma:

"Adding manpower to a late software project makes it later."

Em português:

"Adicionar pessoas a um projeto atrasado fará com que ele atrase ainda mais."

Essa é uma das leis mais famosas da Engenharia de Software.

Ela parece contraintuitiva.

Mas faz completo sentido quando entendemos como projetos realmente funcionam.


A origem da Lei de Brooks

A frase foi criada por Frederick Phillips Brooks Jr., engenheiro da IBM e gerente do desenvolvimento do OS/360, um dos maiores e mais complexos sistemas operacionais da história dos mainframes.

Em 1975, Brooks publicou o livro clássico:

The Mythical Man-Month

Até hoje considerado uma das obras mais importantes da Engenharia de Software.

O livro nasceu da experiência prática.

Brooks percebeu que aumentar equipes durante crises normalmente piorava a situação.


Quem foi Frederick Brooks?

Frederick Brooks trabalhou na IBM durante um período decisivo da computação.

Entre suas contribuições estão:

  • liderança do projeto IBM System/360;

  • coordenação do desenvolvimento do OS/360;

  • estudos sobre arquitetura de computadores;

  • pesquisa em Engenharia de Software.

Seu trabalho moldou a forma como planejamos projetos até hoje.


Matrix explica perfeitamente

Imagine que Neo precisa salvar Zion.

Faltam dois dias.

Morpheus decide recrutar:

100 pessoas completamente novas.

Nenhuma conhece:

  • a Matrix;

  • os Sentinelas;

  • Zion;

  • a Nebuchadnezzar.

O que acontece?

Antes de ajudar...

essas pessoas precisarão aprender.

E quem ensinará?

Justamente Neo e Trinity.

Os dois que já estavam sem tempo.


O paradoxo da produtividade

Muitos gestores pensam:

10 pessoas

↓

10 meses

Logo.

20 pessoas

↓

5 meses

Infelizmente software não funciona assim.

Porque existe algo invisível.

Comunicação.


A matemática escondida

Imagine uma equipe.

2 pessoas.

Existem apenas:

1 canal de comunicação.

Agora.

5 pessoas.

Existem:

10 canais.

Agora.

10 pessoas.

45 canais.

Agora.

20 pessoas.

190 canais.

Cada novo integrante aumenta exponencialmente a quantidade de comunicação necessária.


O COBOL conhece isso muito bem

Imagine um banco.

Projeto crítico.

Equipe original:

6 especialistas COBOL.

Prazo apertado.

Gestão decide contratar:

12 novos desenvolvedores Java.

Eles são excelentes profissionais.

Mas nunca viram:

  • JCL;

  • CICS;

  • Db2;

  • VSAM;

  • RACF;

  • IMS;

  • JES2.

Resultado.

Os seis especialistas passam semanas ensinando.

Quem desenvolve?

Quase ninguém.


Como nasce o problema?

Projeto atrasa.

Gestão entra em pânico.

Contrata mais pessoas.

Treinamento aumenta.

Reuniões aumentam.

Integração aumenta.

Produtividade cai.

Projeto atrasa ainda mais.


Matrix Reloaded

Neo pergunta ao Arquiteto.

— Quantos Escolhidos existiram?

O Arquiteto responde.

— Muitos.

Imagine se, em vez de treinar um Escolhido, resolvessem treinar mil simultaneamente.

O conhecimento seria distribuído.

Mas muito mais lentamente.


O efeito psicológico

Existe um fenômeno interessante.

Equipes pequenas criam ritmo.

Todos sabem quem faz o quê.

Quando a equipe cresce rapidamente.

Aparecem:

  • dúvidas;

  • alinhamentos;

  • reuniões;

  • conflitos;

  • dependências.

O trabalho deixa de ser apenas programação.

Passa a ser coordenação.


O Programador COBOL Padawan

Imagine.

Primeira semana.

Você entra em um projeto.

Recebe:

  • 8 milhões de linhas COBOL;

  • 1.200 JCLs;

  • centenas de COPYBOOKs.

Você pergunta:

— Por onde começo?

Alguém precisa responder.

Esse alguém interrompe o próprio trabalho.


O Agente Smith adora isso

Porque quanto maior a equipe desorganizada.

Maior:

  • ruído;

  • retrabalho;

  • conflitos;

  • inconsistências.

Smith não precisa criar bugs.

A comunicação cria sozinha.


Um exemplo inspirado na Matrix

Neo está lutando contra Smith.

No meio da batalha chegam cinquenta novos soldados.

Todos perguntam ao mesmo tempo:

  • Onde atiro?

  • Quem é Smith?

  • O que é Zion?

  • Onde fica a saída?

  • Como funciona a Matrix?

Neo para de lutar.

Começa a responder perguntas.

Smith agradece.


Quando Brooks NÃO se aplica?

Essa é uma pergunta importante.

A Lei de Brooks não é absoluta.

Adicionar pessoas pode funcionar quando:

  • o trabalho pode ser dividido facilmente;

  • existem módulos independentes;

  • a documentação é excelente;

  • a arquitetura é clara;

  • há tempo para treinamento;

  • o projeto ainda está no início.

Por isso compreender o contexto é essencial.


O impacto no Mainframe

Ambientes IBM Z possuem características particulares.

Conhecimento de:

  • COBOL;

  • CICS;

  • Db2;

  • MQ;

  • RACF;

  • JCL;

  • z/OS.

Não se aprende em dois dias.

Logo.

Projetos críticos dependem muito da experiência acumulada.


Curiosidade

Brooks também criou outra frase famosa.

"The bearing of a child takes nine months, no matter how many women are assigned."

Essa analogia mostra que algumas atividades possuem limites naturais.

Software também.


O custo invisível

Cada novo integrante precisa:

  • ambiente;

  • acessos;

  • documentação;

  • mentor;

  • revisão;

  • treinamento;

  • integração.

Tudo isso consome tempo da equipe experiente.


Atenção!

A Lei de Brooks não significa:

"Nunca contratar."

Ela significa:

"Contratar tarde demais não resolve problemas estruturais."


A diferença

Crescimento planejado

Equipe aumenta gradualmente.


Crescimento desesperado

Equipe dobra durante a crise.


Matrix e a Frota de Zion

Imagine construir cem naves.

Contratar cem pilotos no último dia não acelera a construção.

Talvez nem existam naves suficientes para treiná-los.


Ferramentas ajudam

Hoje temos recursos que reduzem parte desse problema.

  • Wikis técnicas.

  • IBM ADDI.

  • Diagramas automáticos.

  • Pair Programming.

  • IA.

  • Documentação viva.

  • Vídeos internos.

  • Onboarding estruturado.

Mesmo assim.

Aprendizado continua levando tempo.


O papel da IA

A IA pode acelerar bastante o onboarding.

Ela ajuda a:

  • explicar programas COBOL;

  • resumir COPYBOOKs;

  • gerar diagramas;

  • responder dúvidas;

  • localizar dependências.

Mas não substitui o conhecimento do negócio.

Nem a experiência adquirida durante anos.


Os riscos

Comunicação excessiva


Retrabalho


Treinamento insuficiente


Burnout dos especialistas


Mais reuniões


Mais conflitos


Decisões inconsistentes


Erros clássicos

  • Dobrar a equipe durante a crise.

  • Não investir em documentação.

  • Ignorar curva de aprendizado.

  • Acreditar que programação é totalmente paralelizável.

  • Subestimar o conhecimento do negócio.


Boas práticas

  • Planeje crescimento cedo.

  • Documente continuamente.

  • Faça onboarding estruturado.

  • Divida responsabilidades.

  • Automatize tarefas repetitivas.

  • Preserve tempo dos especialistas.

  • Desenvolva novos profissionais antes da emergência.


Aplicabilidade

A Brooks's Law aparece em:

  • COBOL;

  • Java;

  • C#;

  • Python;

  • Cloud;

  • DevOps;

  • IA;

  • ERP;

  • Mobile;

  • Sistemas Bancários.

Sempre que conhecimento especializado é necessário.


O ensinamento do Oráculo

O Oráculo entrega um quebra-cabeça de mil peças para Neo.

Depois coloca cinquenta pessoas ao redor da mesa.

Ela pergunta:

— Terminaremos mais rápido?

Neo pensa.

Algumas pessoas começam a procurar peças.

Outras perguntam onde ficam as bordas.

Outras discutem a estratégia.

Depois de alguns minutos.

Neo sorri.

— Primeiro precisamos aprender a trabalhar juntos.

Ela responde:

"Exatamente. O tempo investido em coordenação cresce junto com a equipe."


Lições para um Programador COBOL Padawan

Se você ingressar em um grande projeto IBM Z, não se preocupe por não produzir imediatamente como os profissionais mais experientes.

Existe uma curva natural de aprendizado.

Você precisará conhecer:

  • a arquitetura;

  • o negócio;

  • os padrões da empresa;

  • os ambientes;

  • as ferramentas;

  • a cultura da equipe.

Ao mesmo tempo, quando você se tornar experiente, lembre-se de documentar e compartilhar conhecimento.

Essa atitude reduz o impacto descrito pela Lei de Brooks e torna o crescimento da equipe muito mais saudável.


Curiosidades

O livro The Mythical Man-Month também apresentou conceitos que continuam atuais:

  • No Silver Bullet (não existe solução mágica para produtividade).

  • Conceitualização é mais difícil que codificação.

  • Comunicação é um dos maiores custos invisíveis de projetos.

  • A importância de arquiteturas consistentes.

Mesmo cinquenta anos depois, essas ideias permanecem extremamente relevantes.


Conclusão — Nem Mesmo Neo Poderia Ensinar Toda Zion em Dois Dias

Na Matrix, Neo tornou-se poderoso porque teve tempo para aprender.

Treinou.

Errou.

Praticou.

Recebeu orientação de Morpheus, Trinity e do Oráculo.

Ninguém nasce especialista em COBOL, CICS ou Db2.

A Lei de Brooks nos lembra justamente disso.

Projetos atrasados raramente precisam apenas de mais pessoas.

Frequentemente precisam de:

  • planejamento melhor;

  • documentação adequada;

  • arquitetura clara;

  • prioridades bem definidas;

  • comunicação eficiente.

Para um Programador COBOL, essa talvez seja uma das lições mais importantes da carreira.

Conhecimento leva tempo para ser construído.

E tempo não pode ser multiplicado simplesmente aumentando o número de cadeiras na sala.

No universo Bellacosa Mainframe existe uma máxima que certamente estaria gravada na porta da sala do Arquiteto:

"Programadores podem ser contratados em um dia. Experiência, confiança e entendimento do negócio não."

Porque, assim como Neo precisou aprender a enxergar o código verde da Matrix antes de transformá-la, toda equipe precisa de tempo para se tornar realmente produtiva. É exatamente essa realidade que Frederick Brooks transformou em uma das leis mais importantes da história da Engenharia de Software.