Idea principale

Uno stesso oggetto è descritto in quattro posti di un prodotto, e ognuno dice quello che gli altri tacciono. Il cuore del codice contiene le regole — cosa è vietato, cosa è obbligatorio, cosa scatena cosa. La base di dati porta i campi, l'unicità, ciò che non può restare vuoto. Le schermate portano i controlli di inserimento, i campi condizionali, i pulsanti disattivati, le liste di scelta. Le traduzioni portano le parole realmente mostrate all'utente, in tutte le lingue.

Una regola può benissimo esistere in uno solo di questi quattro posti. Leggere il cuore del codice e fermarsi lì — il riflesso più naturale, tanto per uno sviluppatore quanto per un agente — produce quindi una descrizione che sembra completa e non lo è.

S'impone un ordine di lettura: le schermate dopo il codice, e prima di chiudere l'argomento. Il raffronto si fa oggetto per oggetto, mai cartella per cartella, perché la suddivisione dell'interfaccia non coincide con quella del server.

Perché è importante

È una condizione di completamento verificabile da terzi: «quest'area è finita» diventa verificabile riga per riga, un'area e un posto per riga, invece di essere dichiarato. Un monitoraggio a questa granularità sopravvive all'interruzione del lavoro ed evita di rifare due volte la stessa lettura.

Ed è ciò che mette a confronto le quattro fonti, quindi ciò che rende visibili le loro contraddizioni.

Sfumature e limiti

Il criterio misura la profondità, mai l'ampiezza. Si possono leggere i quattro posti su una minoranza delle aree del prodotto e ignorare tutto il resto — nel qual caso la regola è perfettamente rispettata e il lavoro molto incompleto.

Il numero quattro non è una legge: corrisponde ai posti in cui quel prodotto deposita informazione. Un'architettura diversa — messaggi scambiati fra servizi, motore di regole esterno — ne aggiungerebbe altri.

Domande aperte

• Come riconoscere, su un'architettura sconosciuta, la lista dei posti in cui l'informazione si deposita, prima di aver cominciato a leggerli?