Idea principale

Quando il codice dice una cosa e la base di dati o la schermata ne dice un'altra, il primo riflesso è dare la colpa alle date: una delle due è in ritardo sull'altra, non c'è niente da concludere. Questo riflesso ha un effetto perverso — archivia come artefatto di metodo proprio il risultato che si stava cercando.

Se le due affermazioni provengono dallo stesso momento del prodotto — la stessa versione, in produzione —, nessuno sfasamento è in causa. Il prodotto si contraddice da solo: un vincolo di unicità che il business smentisce, un controllo di inserimento che nessuna verifica lato server ripete, un campo obbligatorio sulla schermata e facoltativo nella base. È esattamente il tipo di divergenza che una descrizione incrociata serve a far emergere.

Da qui la precauzione sull'ordine: si datano prima le fonti, così che ogni contraddizione residua sia del prodotto e non del dispositivo di osservazione.

Perché è importante

Trasforma un fastidio metodologico in rendimento. Il grosso del valore di un repertorio non viene dalle regole che ricopia in bella copia, ma dai punti in cui due parti del prodotto non dicono la stessa cosa — e ognuno diventa un debito su cui decidere o un difetto con implicazioni di sicurezza.

Evita anche di «levigare» la descrizione: davanti a due affermazioni contraddittorie, la tentazione è tenerne una e andare avanti, il che cancella la scoperta.

Sfumature e limiti

La regola richiede una disciplina di datazione esemplare, altrimenti produce l'errore opposto: scambiare uno sfasamento fra fonti per un'incoerenza del prodotto, e aprire scostamenti che non esistono.

E non tutte le contraddizioni hanno lo stesso statuto: una differenza fra due applicazioni può essere una scelta di portata consapevole e non un difetto, a patto che quella scelta sia scritta da qualche parte.

Domande aperte

• Quale parte di queste contraddizioni è accettata consapevolmente dai team, e come distinguere la decisione tacita dal difetto che nessuno ha mai visto?