Ideia principal

"Quem cria o bug corrige o bug" se lê espontaneamente como uma regra de tratamento: ela diria quem faz o trabalho de correção. O efeito principal dela, no entanto, está antes da correção.

Um desenvolvedor que sabe que seus defeitos voltarão direto para ele entrega de outro jeito. Ele testa mais, revisa melhor, empurra com menos vontade uma mudança frágil para cumprir uma data, aceita com menos facilidade programar em cima de uma ambiguidade forte. A regra é um incentivo antes de ser uma alocação.

Ela não garante nada: um desenvolvedor cuidadoso pode produzir um defeito, e uma regra de alocação não substitui um sistema de produção. O que ela muda é a arbitragem privada que cada um faz na hora de entregar, quando ninguém está olhando.

Por que isso importa

Isso responde à objeção do custo: aplicar a regra atrapalha o planejamento, atrasa a funcionalidade seguinte, traz alguém de volta a um assunto que já tinha deixado. Esse custo é real, mas ele se compara ao fluxo de defeitos que reduz, e não apenas ao tempo de correção que desloca.

Isso também explica por que as exceções custam caro: cada exceção não desloca só uma correção, ela enfraquece o incentivo para todas as entregas que virão.

Nuances e limites

O incentivo supõe que o desenvolvedor tenha tido controle sobre o que entregava. Pressionado por um prazo imposto ou por uma especificação que ele foi proibido de discutir, ele sofre a regra sem poder responder a ela — e ela vira uma punição.

Ela também não diz nada sobre os defeitos vindos do legado ou de várias contribuições, em que o autor não é identificável.

Questões em aberto

• A partir de qual intervalo entre a entrega e o aparecimento do defeito o incentivo deixa de agir sobre a maneira de entregar?