Idea principale

Scrivere codice costava tempo, e questo costo produceva un effetto collaterale che nessuno aveva deciso: prima di andare avanti bisognava spesso parlarne, decidere, far rileggere, capire quello che si stava facendo. La comprensione non era garantita da una disciplina: la imponeva il prezzo del lavoro.

Quando bastano poche ore dove prima servivano giorni, questo argine di fatto scompare — e non lascia niente dietro di sé, perché non era mai stato istituito. Si può allora andare più veloci della propria comprensione, davanti a schermate che rispondono, a un database che esiste e a un'API che gira, senza che nessun momento obblighi a sapere perché le cose sono fatte così.

La disciplina che manca non è quindi una disciplina perduta: è una disciplina che non aveva mai avuto bisogno di esistere, e che va scritta per la prima volta.

Perché è importante

Spiega perché anche i team più esperti si lasciano sorprendere. Non hanno allentato le loro pratiche; hanno perso un meccanismo involontario su cui quelle pratiche si appoggiavano senza saperlo.

Indica anche il rimedio: non si tratta di tornare alle pratiche di prima, ma di rendere esplicito — revisione obbligatoria, decisione di architettura scritta, budget di comprensione per ogni funzionalità — quello che la lentezza produceva gratis.

Sfumature e limiti

Andare oltre la propria comprensione non è sempre un difetto: è proprio quello che si cerca in esplorazione, quando si vuole vedere come sarebbe una soluzione prima di sapere se vale. Il pericolo comincia quando l'esplorazione diventa produzione senza che nessuno abbia sancito il passaggio.

E la lentezza imponeva la conversazione senza mai garantirne la qualità: molti sistemi lenti sono stati mal compresi lo stesso.

Domande aperte

• Da quale segnale un team riconosce che un prototipo esplorativo è appena stato promosso in produzione senza una decisione esplicita?