Idea principale

Uno sviluppatore che riprende in mano un difetto introdotto da lui stesso non si limita a riparare. È l'unica persona in grado di confrontare ciò che credeva di consegnare con ciò che è realmente accaduto. Vede dove la sua comprensione del bisogno era incompleta, se mancava il test che avrebbe intercettato il caso, se la specifica lasciava aperta l'ambiguità che ha risolto da solo, se l'architettura rendeva probabile l'errore.

Un altro sviluppatore che corregge al suo posto trova la causa tecnica, non la causa decisionale. Ripara il sintomo senza che l'informazione risalga fino al punto in cui avrebbe cambiato qualcosa.

È questo ciclo — consegnare, scontrarsi con la conseguenza, riconoscere ciò che mancava — a produrre il miglioramento. Non è un effetto collaterale della correzione: ne è il valore principale.

Perché è importante

Offre un criterio di progettazione per le politiche della qualità: una politica che ottimizza i tempi di correzione senza chiedersi chi corregge compra rapidità sacrificando l'apprendimento.

Spiega anche perché in un team si ripetono gli stessi errori di progettazione. Non nascono da una mancanza di competenza, ma da un circuito di informazione che non torna mai all'autore.

Sfumature e limiti

Il ciclo si chiude solo se il difetto viene ricondotto alla sua causa, e non soltanto alla sua riga di codice: correggere senza dare un nome a ciò che è mancato a monte produce solo una riparazione in più.

E il ciclo ha una scadenza: più tardi compare il difetto, meno l'autore ricorda che cosa credeva di fare al momento della consegna.

Domande aperte

• Dove registrare ciò che la correzione rivela — test mancante, specifica ambigua, architettura fragile — perché agisca sulla consegna successiva invece di restare nella testa di chi ha corretto?