Idée principale

« Celui qui crée le bug le corrige » se lit spontanément comme une règle de traitement : elle dirait qui fait le travail de correction. Son effet principal se situe pourtant en amont de la correction.

Un développeur qui sait que ses défauts lui reviendront directement livre autrement. Il teste davantage, il relit mieux, il pousse moins volontiers un changement fragile pour tenir une date, il accepte moins facilement de coder sur une ambiguïté forte. La règle est une incitation avant d'être une affectation.

Elle ne garantit rien : un développeur consciencieux peut produire un défaut, et une règle d'affectation ne remplace pas un système de production. Ce qu'elle change est l'arbitrage privé que fait chacun au moment de livrer, quand personne ne regarde.

Pourquoi c'est important

Cela répond à l'objection du coût : appliquer la règle perturbe le planning, ralentit la fonctionnalité suivante, ramène quelqu'un sur un sujet qu'il a quitté. Ce coût est réel, mais il se compare au flux de défauts qu'il réduit, pas seulement au temps de correction qu'il déplace.

Cela explique aussi pourquoi les exceptions coûtent cher : chaque exception ne déplace pas seulement une correction, elle affaiblit l'incitation pour toutes les livraisons à venir.

Nuances et limites

L'incitation suppose que le développeur ait eu prise sur ce qu'il livrait. Contraint par un délai imposé ou par une spécification qu'on lui a interdit de discuter, il subit la règle sans pouvoir y répondre — et elle devient une sanction.

Elle ne dit rien non plus des défauts issus du legacy ou de plusieurs contributions, où l'auteur n'est pas identifiable.

Questions ouvertes

• À partir de quel délai entre la livraison et l'apparition du défaut l'incitation cesse-t-elle d'opérer sur la manière de livrer ?