Ideia principal

Escrever código custava tempo, e esse custo produzia um efeito colateral que ninguém tinha decidido: antes de ir adiante, muitas vezes era preciso conversar, decidir, pedir revisão, entender o que se estava fazendo. A compreensão não era garantida por uma disciplina, era imposta pelo preço do gesto.

Quando algumas horas bastam onde antes eram precisos vários dias, essa proteção de fato desaparece — e não deixa nada atrás de si, porque nunca tinha sido instituída. Dá para avançar então mais rápido que a própria compreensão, sobre telas que respondem, um banco de dados que existe e uma API que roda, sem que nenhum momento obrigue a saber por que as coisas são feitas assim.

A disciplina que falta não é, portanto, uma disciplina perdida: é uma disciplina que nunca precisou existir, e que é preciso escrever pela primeira vez.

Por que isso importa

Isso explica por que os times mais experientes também se surpreendem. Eles não afrouxaram as práticas; perderam um mecanismo involuntário no qual as práticas deles se apoiavam sem saber.

Isso também orienta o remédio: não se trata de voltar às práticas de antes, mas de tornar explícito — revisão obrigatória, decisão de arquitetura escrita, orçamento de compreensão por funcionalidade — o que a lentidão produzia de graça.

Nuances e limites

Ir além da própria compreensão nem sempre é um defeito: é exatamente o que se busca na exploração, quando você quer ver com o que uma solução se pareceria antes de saber se ela vale. O perigo começa quando a exploração vira produção sem que ninguém tenha registrado a passagem.

E a lentidão impunha a conversa sem nunca garantir a qualidade dela: muitos sistemas lentos foram mal compreendidos mesmo assim.

Questões em aberto

• Por qual sinal um time reconhece que um protótipo exploratório acabou de ser promovido a produção sem decisão explícita?