Ideia principal

Um desenvolvedor que retoma um defeito que ele mesmo introduziu não está apenas consertando. Ele é a única pessoa em posição de comparar o que achava que estava entregando com o que de fato aconteceu. Ele vê onde seu entendimento da necessidade estava incompleto, se o teste que teria pegado o caso não existia, se a especificação deixava a ambiguidade que ele resolveu sozinho, se a arquitetura tornava o erro provável.

Outro desenvolvedor que corrige no lugar dele encontra a causa técnica, não a causa da decisão. Ele conserta o sintoma sem que a informação volte ao ponto em que teria mudado alguma coisa.

É esse ciclo — entregar, encontrar a consequência, reconhecer o que faltava — que produz a melhoria. Ele não é um efeito colateral da correção: é o valor principal dela.

Por que isso importa

Isso dá um critério de concepção para as políticas de qualidade: uma política que otimiza o prazo de correção sem perguntar quem corrige compra rapidez suprimindo o aprendizado.

Isso também explica a repetição dos mesmos erros de concepção dentro de um time. Eles não vêm de falta de competência, mas de um circuito de informação que nunca volta ao autor.

Nuances e limites

O ciclo só se fecha se o defeito for ligado à sua causa, e não apenas à sua linha de código: corrigir sem nomear o que faltou lá atrás produz mais um conserto.

E ele tem um prazo: quanto mais tarde o defeito aparece, menos o autor se lembra do que achava que estava fazendo na hora de entregar.

Questões em aberto

• Onde registrar o que a correção revela — teste faltando, especificação ambígua, arquitetura frágil — para que isso aja sobre a próxima entrega em vez de ficar na cabeça de quem corrigiu?