Idea principale

«Chi crea il bug lo corregge» si legge spontaneamente come una regola di gestione: direbbe chi fa il lavoro di correzione. Il suo effetto principale, però, si colloca a monte della correzione.

Uno sviluppatore che sa che i suoi difetti gli torneranno indietro direttamente consegna in modo diverso. Testa di più, rilegge con più cura, è meno propenso a spingere una modifica fragile per rispettare una data, accetta meno facilmente di scrivere codice su un'ambiguità forte. La regola è un incentivo prima ancora di essere un criterio di assegnazione.

Non garantisce nulla: uno sviluppatore coscienzioso può produrre un difetto, e una regola di assegnazione non sostituisce un sistema di produzione. Ciò che cambia è il calcolo privato che ciascuno fa al momento di consegnare, quando nessuno guarda.

Perché è importante

Risponde all'obiezione del costo: applicare la regola scombina la pianificazione, rallenta la funzionalità successiva, riporta qualcuno su un'attività che aveva lasciato. Questo costo è reale, ma va confrontato con il flusso di difetti che riduce, non solo con il tempo di correzione che sposta.

Spiega anche perché le eccezioni costano care: ogni eccezione non sposta soltanto una correzione, indebolisce l'incentivo per tutte le consegne future.

Sfumature e limiti

L'incentivo presuppone che lo sviluppatore avesse voce in capitolo su ciò che consegnava. Se è vincolato da una scadenza imposta o da una specifica che gli è stato vietato discutere, subisce la regola senza poterle rispondere — e la regola diventa una sanzione.

Non dice nulla, inoltre, dei difetti nati dal legacy o da più contributi, dove l'autore non è identificabile.

Domande aperte

• Oltre quale intervallo fra la consegna e la comparsa del difetto l'incentivo smette di agire sul modo di consegnare?