Idea principale

Il contesto che assorbe le email di un condominio comincia con un file context.md e una frase: aggrega e suddividi per temi. Questo livello regge finché non ci si accorge che lo stato attuale ha cancellato la storia del cantiere — e si aggiunge un registro cronologico. Regge di nuovo finché gli omonimi e i doppi cognomi non producono schede doppie — e si scrivono direttive specifiche. Poi il file supera le mille righe e la finestra del modello ci si perde — si tolgono le direttive, poi si suddivide per tema. Poi il vocabolario tecnico si ripete in ogni file — lo si centralizza in un glossary.md.

Ogni gradino ha quindi una causa che si può nominare, e questa causa è sempre un guasto del livello precedente, mai un miglioramento desiderato in astratto. È ciò che distingue una crescita di complessità dall'overengineering: la prima risponde a un bisogno che si è manifestato, il secondo a un'architettura che si trovava bella. Il test è disponibile prima di ogni livello — quale problema concreto, già incontrato, elimina questo livello?

Anche l'ordine che ne risulta non è intercambiabile: si può suddividere in modo pulito per tema solo dopo aver tolto le regole di trattamento, altrimenti non si sa che cosa ricopiare in ogni pezzo. E a ogni gradino si dispone di un sistema che funziona — non di un lavoro a metà che servirà solo una volta finito.

Perché è importante

Rovescia il modo di affrontare un sistema descritto da qualcun altro. Davanti a un modello completo — cartelle, manifesti di caricamento, note atomiche collegate —, la lettura naturale è quella di un progetto da installare; la lettura utile è quella di una traiettoria, di cui si riprendono solo i livelli di cui si è già incontrato il guasto.

Dà anche un criterio di decisione per le versioni successive: si cambia versione perché i bisogni sono cresciuti, e constatare che un bisogno non è cresciuto è una ragione sufficiente per restare dove si è.

Sfumature e limiti

Certi guasti sono prevedibili per chi ha già costruito un sistema simile, e aspettare che si verifichino costa una migrazione che si sarebbe potuta evitare. La regola protegge dall'overengineering, non dall'ingenuità.

E non tutti i guasti si manifestano come una mancanza. La perdita di precisione di un modello su un file lungo non fa scattare nessun allarme: degrada lentamente risposte che restano plausibili, e il gradino successivo si sale solo se qualcuno ha dato un nome al meccanismo in anticipo.

Domande aperte

• Che cosa indica, in un sistema in funzione, che non basta più, quando il guasto non prende la forma di una risposta palesemente sbagliata?