Idea principale

Descrivere un software presuppone di fissare un momento: una versione del codice, e tutto ciò che gira insieme a essa — la base com'è a quella versione, le schermate di quella versione, le traduzioni di quella versione. È l'istantanea, e stabilisce cosa ha il diritto di entrare.

Un export della base di dati prodotto qualche mese prima sembra comunque utilizzabile: descrive lo stesso prodotto, più o meno. In realtà descrive un prodotto più vecchio, e quel «più o meno» è proprio ciò che si stava cercando. Su un'area intera, oggetti presenti nel codice non avevano nessuna tabella corrispondente nell'export — e la conclusione tratta fu che non esistessero.

La regola non è «verificare la data prima di concludere», perché questa vigilanza non regge nel tempo. È più radicale: una fonte di un'altra data si sostituisce con una versione aggiornata, oppure se ne fa a meno.

Perché è importante

È ciò che impedisce un errore muto. Una fonte superata non produce un messaggio d'errore: produce un'assenza, e un'assenza si legge come un'informazione — «questo oggetto non esiste» — quando invece non dice nulla.

E la regola si controlla senza bisogno di giudizio: ogni fonte porta la sua versione, oppure esce dal perimetro. È una condizione di ammissione, non una cautela di lettura.

Sfumature e limiti

L'esigenza vale solo per le fonti che dovrebbero descrivere lo stato del prodotto. I materiali che riportano ciò che dicono le persone — resoconti di interviste, ticket — sono datati per natura e conservano il loro valore: non descrivono il prodotto, descrivono un uso.

Il vincolo ha un costo reale: ricostruire una fonte alla versione giusta richiede tempo, e la tentazione di servirsi di quella che si ha sottomano si ripresenta a ogni area.

Domande aperte

• Con quale ritmo rifare l'istantanea, sapendo che ogni sfasamento trasforma progressivamente le fonti disponibili in fonti inammissibili?