Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
Processar especificações de arquitetura e simular casos de exceção na cabeça é tentador. O código na mente não tem bugs e é perfeito. No entanto, se você continua pensando sem abrir o editor, isso não é cautela, é simplesmente medo do fracasso. Um documento de design gigantesco criado para evitar incertezas acaba desmoronando na primeira mudança de requisito assim que o desenvolvimento começa.
Para desenvolvedores que perdem tempo presos na paralisia de análise, organizamos um fluxo de trabalho para destruir o perfeccionismo e lançar um protótipo hoje mesmo.
Comparar todos os tipos de frameworks e arquiteturas antes de escrever uma única linha de código causa uma sobrecarga cognitiva extrema. Ficar obcecado com o tratamento de erros que tem menos de 0,1% de chance de acontecer, ou construir camadas de abstração antes mesmo de os requisitos saírem, é uma reação clássica de aversão à perda.
De acordo com pesquisas da McKinsey e da Leadership IQ com empresas da Fortune 500, o tempo desperdiçado com indecisão e análise excessiva ultrapassa 53.000 dias por ano. Em custos de pessoal, isso equivale a 250 milhões de dólares jogados no lixo sem nenhum resultado. A produtividade individual dos desenvolvedores também cai mais de 40% devido à pré-otimização.
Se você perceber que a simulação mental está durando muito, deve encerrá-la à força com um sistema. Basta aplicar o padrão de solução spike (spike solution) do Extreme Programming (XP) ao seu dia a dia.
Se você está preso na fase de planejamento há 2 semanas, o problema não é a falta de especificações, mas sim a falta de contexto de execução. Nesses casos, você deve fechar todos os documentos de design e impor um timeboxing de 30 minutos.
Um protótipo com 30% de conclusão deixa de lado o tratamento de erros, a integração com banco de dados e a sofisticação da UI. O objetivo é apenas verificar se o resultado desejado aparece ao inserir os valores de entrada. É por isso que as equipes de produto do Vale do Silício fazem reuniões usando protótipos funcionais em vez de documentos de requisitos abstratos. A incerteza só desaparece quando você clica na tela.
Vamos calcular com base no Custo de Atraso (Cost of Delay). Se 4 engenheiros que recebem US$ 2.025 por semana passarem 2 semanas repetindo reuniões de arquitetura, isso resultará em uma perda direta e indireta de US$ 16.200.
| Item de Avaliação | Desenvolvimento Focado em Especificação | Desenvolvimento Focado em Protótipo | Efeito |
|---|---|---|---|
| Definição de Requisitos Iniciais | 2 a 4 semanas (Redação de documentos) | 30 minutos a 1 dia (Criação de spike) | Redução de 90% no tempo |
| Reuniões de Revisão de Planejamento | Média de 8 a 12 vezes (Debate abstrato) | Média de 2 a 3 vezes (Baseado em demonstração) | Redução de 70% nas reuniões |
| Correção de Erros de Dire direção | Reconstrução de toda a estrutura | Descarte de rascunho de 30 minutos | Minimização de custos de refatoração |
| Velocidade de Revisão de PR | Ocorre gargalo | Lançamento antecipado de Draft PR | Aumento de 30% na velocidade de revisão |
Quando o pensamento e a implementação se misturam, você continua olhando para trás enquanto escreve o código. É por isso que o tempo de trabalho diário é dividido rigidamente entre a fase de análise e a fase de implementação pura. É o mesmo que o princípio de "tempo fixo, escopo variável" da metodologia Shape Up da Basecamp. Defina o tempo primeiro e, se parecer que não vai terminar dentro dele, descarte as funcionalidades.
Quando você encontrar um ponto em que está travado, o critério para contorná-lo sem cair em reflexões profundas segue o conceito de "dívida intencional e deliberada" do quadrante de dívida técnica de Martin Fowler. Se for um código que pode ser facilmente alterado mais tarde, é melhor escolher o desvio mais simples agora e fazer o commit.
Jeff Bezos disse para decidir e agir quando a certeza atingir o nível de 70%. Esperar até que esteja mais de 90% perfeito é matar a velocidade.
Se você esconder o código porque ele não está perfeito, isso retornará como um retrabalho maior mais tarde. A equipe de engenharia da Shopify envia Draft PRs não para ter o código perfeito inspecionado, mas para validar a direção do trabalho.
É uma boa prática manter o tamanho do PR abaixo de 200 a 300 linhas. Adicionar uma tag WIP dizendo "Apenas feedback sobre a direção da estrutura do algoritmo" também reduz a carga sobre o revisor.
O código inicial não é sua obra de arte, mas apenas uma hipótese a ser testada. Quando o feedback chegar, basta refleti-lo rapidamente e seguir em frente.
Uma arquitetura virtual perfeita nunca sai da mente. Uma única linha de rascunho imperfeita, mas funcional, escrita hoje se torna sua verdadeira habilidade. Você só pode escapar do pântano do custo de atraso quando abandona a desculpa do perfeccionismo.
