A Mi vuoi spiegare cosa lega la frase che hai detto relativa al feed.

Mi riferivo alle considerazioni relative alle dichiarazioni in etichetta degli alimenti e l’instabilità invisibile della realtà, ed anche al fatto che questo non modifica il comportamento dei decisori.

La frase sta a indicare la differenza tra ciò che crediamo che il sistema faccia e ciò che i dati mostrano che il sistema fa davvero. Tieni presente che per me il fabbricante di alimenti rappresenta il riferimento qualitativo del settore feed. Per me deve esserlo, quindi opero affinchè lo diventi.

S Spiegati meglio.

Nel nostro vissuto feed non vi era un grande flusso di dati, era il luogo dove convergevano: segnali operativi, dichiarazioni “ufficiali” dell’etichetta/ e la sua configurazione, interpretazioni storiche dei tecnici ed anche comportamenti reali osservati. Dobbiamo tener presente che nell’epoca antibiotico centrica gli altri apporti erano del tutto poco considerati. Erano un male necessario? Forse si ma non importava molto di quel 0,5%, e questa scarsa considerazione la trasciniamo ancora oggi. L’importante, in quell’epoca, era l’antibiotico come fattore di crescita, come trattamento preventivo. Era l’epoca in cui il Veterinario aveva un ruolo importante, anche se non era il vero decisore, il nutrizionista non era ancora nato era un semplice formulista: far funzionare bene con quello che c’è. La tensione nasce quando i livelli non coincidono più, e questa è la nostra epoca attuale, secondo me. Una cosa può essere formalmente corretta: configurazione valida, ridondanze presenti (aumentate dopo la riduzione degli antibiotici), metriche entro la soglia (tutto stabilito come qualità e quantità per quanto riguarda i micro ingredienti), nessun allarme critico (ma chi ci fa caso?!?). E tuttavia il tutto è intrinsecamente instabile. E questo, almeno per me, è un rischio, in particolare per un settore nel quale i marchi hanno una parte preponderante.

A Questo succede spesso nei sistemi maturi.

E’ vero. Esaminiamo il perchè. Perchè le architetture accumulate nel tempo sviluppano: dipendenze implicite, compensazioni reciproche, workaround (lavori di contorno) diventati normali, ridondanze che non aumentano più resilienza ma complessità. Visto da fuori sembra tutto robusto (si fanno dei convegni celebrativi), ma in realtà, il tutto, è fragile perchè: sopravvive grazie ad equilibri casuali, senza la comprensione del comportamento. Ed è proprio questo: la instabilità invisibile. Il sistema continua a funzionare abbastanza da confermare le convinzioni pregresse, mentre i dati stanno a mostrare segnali contrari.

S Molti tecnici, anche senza volerlo, trasformano le proprie decisioni storiche in dogmi. Ad esempio: “abbiamo aggiunto questi livelli di ridondanza perchè servivano a facilitare le vendite”, “questo componente non va toccato (per usufruire della pubblicità markettara di…), “Più duplicazione = più sicurezza”.

In parte è vero anche l’ultima considerazione mi ricorda “una pallettata di terapeutico è bene, due meglio”. Queste considerazioni erano corrette all’epoca, ma sono cambiati: carichi, latenze, topologia, failure mode, comportamento distribuito, interazioni emergenti. Dato che le convinzioni iniziali restano, nasce il bias molto potente: più hai investito in una scelta, più fatica fai ad ammettere che ora possa essere controproducente oltrechè inutile.

A Potrei dire: siete sicuri che state difendendo la resilienza e non solo la storia della vostra architettura?

Fermiamoci sulla ridondanza. La ridondanza non è automaticamente resilienza, oltre ad una certa soglia può produrre: feedback loop, race condition, divergenze di stato, tempi di convergenza peggiori, maggiore superficie di incoerenza, cascata di retry, amplificazioni dei fault, aumento degli x files. A volte togliere una ridondanza aumenta la prevedibilità, non perché il sistema diventa più semplice in senso estetico, ma perché riduce le interazioni  non osservabili, riduce gli strati intermedi, elimina compensazioni oscure. Ma questo può spaventare i tecnici esperti perché sembra di togliere sicurezza. Abbiamo sempre fatto in questo modo e non abbiamo avuto dei problemi.

A: Questo lo dicono i classici fornitori, lo abbiamo notato.

Si concordo, ma riducendo le ridondanze si sta eliminando una complessità non lineare, una dipendenza fantasma, delle sincronizzazioni inutili. La frase che vi ha colpito non è mia, viene da Popper: Una teoria che non può essere smentita smette di essere utile. Vediamo il pensiero in un modello sano: “Pensiamo che il sistema funzioni così. Vediamo se i dati lo confermano.”. In un modello patologico: “Il sistema DEVE funzionare così, quindi i dati sono interpretati per confermare la teoria.”. E qui diventa difficile essere il garante tecnico del sistema. I dati iniziano ad essere trattati come: rumore, eccezioni, casi limite, anomalie temporanee, ed invece stanno segnalando: “La vostra mappa mentale non descrive più il territorio.”. E questo se lo può permettere chi vuole sbandierare di essere l’asse portante?

S: Ma perché questa paura e questo non voler considerare i dati?

Adesso beviamoci qualcosa di fresco e poi tocchiamo la paura del cambiamento.