Angolo

Ogni livello del contesto che assorbe cinquecento email condominiali è stato aggiunto in seguito a un guasto datato del livello precedente: il registro cronologico perché l'aggregazione aveva cancellato le date del cantiere, il file di direttive perché le regole di trattamento soffocavano sotto il materiale, la suddivisione in quindici file tematici perché il context.md aveva superato le mille righe, il glossario perché lo stesso vocabolario tecnico si ripeteva ovunque. L'architettura finale — direttive, glossario, indice, file tematici — si legge quindi come l'elenco dei guasti incontrati, nel loro ordine di comparsa; e poiché questo elenco è proprio ciò che manca a chiunque la riprenda da altrove, un sistema copiato dalla sua forma restituisce solo la struttura di chi l'ha subito, lasciando intatti i guasti che non si sono ancora incontrati.

Sintesi

I quattro guasti della serie non hanno niente in comune quanto alla causa. Uno è una cancellazione voluta che non produce alcun errore — una scheda esatta, semplicemente senza memoria. Un altro è un disaccordo di organizzazione, in cui la macchina ha lavorato bene e ciò che restituisce non è la struttura di nessuno di quelli che dovranno servirsene. Un terzo è un effetto di volume che si ritorce contro il modello stesso. L'ultimo è una ridondanza di vocabolario. Ciò che li unisce è una cosa sola: nessuno era visibile dal gradino precedente, e ciascuno ha potuto essere nominato solo dopo essere stato subito.

Da qui segue l'ordine, che non è intercambiabile: si suddivide in modo pulito per tema solo dopo aver tolto le regole dal file, altrimenti non si sa che cosa ricopiare in ogni pezzo. E da qui segue lo statuto particolare del primo gradino — non produce un sistema, produce l'inventario dei guasti futuri, il che rende normale e non costoso sostituirlo, e spiega perché questo inventario non si possa prendere in prestito da qualcun altro: un'architettura compiuta mostra solo le sue risposte.

Resta la condizione che autorizza l'intero approccio, e che nessuno di questi gradini enuncia. Riparare dopo il guasto presuppone che il guasto si paghi con una deviazione e non con una perdita — la storia mancante si ritrova nelle email grezze conservate accanto, un fornitore associato male si corregge riaprendo un messaggio. Su un materiale in cui l'errore non si recupera, la costruzione per guasti successivi smette di essere un metodo e diventa un azzardo.

Tensioni / contraddizioni

Due indicazioni della stessa serie non tirano nella stessa direzione. Una dice di salire di gradino solo quando il precedente non basta più; l'altra dice che la prima versione è fatta per essere buttata. Riparare a piccoli passi e ripartire da zero sono due mosse diverse, e niente dice in quale momento una delle due smette di essere quella giusta.

Altra tensione, tra il principio e la pratica di chi lo enuncia: raccomanda di partire da un file e di avanzare per guasti, mentre tiene un sistema di contesti completo — cartelle, manifesti di caricamento, note collegate — di cui è già alla terza versione. Il consiglio è rivolto a chi comincia; non descrive la posizione di chi lo dà.

Domande

• Un sistema ereditato — ripreso da un collega, da un modello pubblico — può produrre i propri guasti abbastanza in fretta perché li si capisca, o bisogna averlo costruito da sé per vederli?
• Quanti gradini può salire insieme un team, quando il guasto è avvertito solo dalla persona che tratta il materiale?
• Che ne è di un livello il cui guasto d'origine è scomparso — perché la soglia che l'aveva motivato è cambiata — e che nessuno pensa a smontare?