s a n d i

Ho visto questa scena ripetersi in almeno una dozzina di uffici tra Milano e Bologna: un team entusiasta seduto attorno a un tavolo, convinto che basti applicare i principi di Sandi per risolvere anni di debito tecnico e processi decisionali farraginosi. Di solito, l'errore parte da un manager che ha letto un articolo superficiale e decide di stravolgere l'architettura aziendale dall'oggi al domani. Risultato? Dopo sei mesi e circa 150.000 euro buttati tra consulenze esterne e ore uomo sprecate, l'azienda si ritrova con un sistema ancora più rigido di prima, dipendenti frustrati che rassegnano le dimissioni e una produttività calata del 30%. Non è colpa della metodologia in sé, ma della convinzione arrogante che la teoria si traduca in pratica senza attriti.

L'illusione della flessibilità immediata e i costi di Sandi

Il primo errore che commetti è pensare che l'adozione di questi schemi ti faccia guadagnare tempo fin dalla prima settimana. Nella realtà dei fatti, ho osservato che i primi tre mesi sono un bagno di sangue finanziario. Quando decidi di isolare le dipendenze e rendere ogni componente autonomo, stai triplicando il lavoro di progettazione iniziale. Se un programmatore senior prima impiegava due giorni per consegnare una funzione, ora ne impiegherà sei.

Molti imprenditori non mettono a budget questa fase di rallentamento. Pensano di poter mantenere le stesse scadenze di consegna mentre ristrutturano le fondamenta del proprio software o della propria organizzazione. Non funziona così. Se non hai almeno tre mesi di ossigeno finanziario per coprire il calo di output, finirai per fare le cose a metà. E fare le cose a metà con questo metodo è peggio che non farle affatto: ti ritrovi con un'architettura "ibrida" che è un labirinto di astrazioni inutili dove nessuno sa più dove mettere le mani.

Dalla mia esperienza, il costo reale si palesa quando devi formare il personale. Non puoi pretendere che un team abituato a lavorare a compartimenti stagni comprenda immediatamente come gestire messaggi e interfacce senza creare accoppiamenti pericolosi. Ho visto aziende spendere 20.000 euro in corsi di formazione teorici, per poi scoprire che i programmatori tornavano alla scrivania e scrivevano lo stesso codice di prima, solo con nomi delle classi più fantasiosi. La soluzione non è un corso, ma l'affiancamento costante sui progetti reali, accettando che per un lungo periodo la velocità di crociera sarà ridotta.

Il mito della manutenibilità infinita

C'è una bugia che circola spesso nei corridoi del reparto IT: "Se lo facciamo bene ora, non dovremo più toccarlo per anni". Questa è una sciocchezza pericolosa. L'obiettivo di una struttura ben progettata non è smettere di lavorarci, ma poterla cambiare senza che tutto esploda.

Molti cadono nell'errore dell'over-engineering. Iniziano a creare interfacce per problemi che non esistono ancora, aggiungendo strati di complessità "per sicurezza". Ho analizzato un progetto l'anno scorso dove il team aveva creato un sistema di gestione dei pagamenti così astratto che poteva teoricamente supportare le criptovalute, i baratti e le pietre preziose. Peccato che l'azienda vendesse solo abbonamenti mensili via carta di credito. Avevano speso due mesi per costruire un'astrazione che non sarebbe mai servita, rendendo il debugging un incubo perché bisognava saltare attraverso dieci file diversi per trovare dove veniva effettivamente processata la transazione.

L'approccio corretto è la prudenza. Non astrarre finché non hai almeno tre casi d'uso concreti e identici. Se lo fai prima, stai solo scommettendo i soldi dell'azienda su un futuro che probabilmente non arriverà mai. Il debito tecnico non è sempre il male; a volte è una scelta consapevole per arrivare sul mercato prima della concorrenza. Se passi troppo tempo a rendere tutto perfetto, quando uscirai con il prodotto il mercato sarà già cambiato.

Misurare il successo con le metriche sbagliate

Un errore che vedo compiere regolarmente dai direttori tecnici è valutare l'efficacia del cambiamento basandosi sulla "pulizia" del codice o sulla bellezza del diagramma di flusso. A nessuno frega niente se il tuo sistema è elegante se il business sta perdendo soldi.

Il fallimento dei test di copertura

Molti pensano che avere il 100% di test automatizzati sia la prova del successo. Ho visto sistemi con una copertura totale che erano comunque impossibili da modificare perché i test erano accoppiati in modo maniacale all'implementazione. Ogni volta che cambiavi una riga di logica, dovevi cambiare cinquanta test. Questo non è risparmiare tempo, è creare una prigione di codice.

La soluzione pratica è testare il comportamento, non la struttura interna. Se cambi il modo in cui il sistema calcola lo sconto ma il risultato finale per il cliente rimane lo stesso, i tuoi test non dovrebbero nemmeno accorgersene. Se si rompono, significa che hai fallito nel creare il giusto isolamento.

La trappola della velocità di sviluppo

Un'altra metrica ingannevole è la velocità dei singoli sviluppatori. In un sistema ben organizzato, la velocità individuale potrebbe persino diminuire, perché ogni modifica richiede una riflessione più profonda sull'impatto sistemico. Quello che deve aumentare è la velocità del team nel lungo periodo e la riduzione dei bug che tornano indietro dal controllo qualità. Se dopo un anno di applicazione di queste tecniche il numero di regressioni non è calato drasticamente, allora stai sbagliando qualcosa di fondamentale nell'applicazione pratica della teoria.

Gestire la resistenza umana al cambiamento tecnico

Puoi avere il miglior piano tecnico del mondo, ma se il tuo team senior si sente minacciato, lo saboterà. Ho lavorato con un'azienda di logistica dove il capo programmatore, un uomo che era lì da quindici anni, vedeva ogni tentativo di modernizzazione come un attacco personale alla sua competenza.

Ogni volta che si cercava di introdurre un'architettura più snella e disaccoppiata, lui trovava un caso limite oscuro per dimostrare che "non avrebbe funzionato". Questo ha portato a mesi di discussioni sterili che hanno bloccato il progetto. La soluzione non è tecnica, è politica. Devi coinvolgere queste persone nel processo decisionale rendendole responsabili dei risultati, non solo esecutori di una visione calata dall'alto.

Spesso l'errore è cercare di imporre un cambiamento totale in una volta sola. È molto più efficace individuare un modulo piccolo, isolato e non critico, e usarlo come laboratorio. Se funziona lì, i risultati parleranno da soli e la resistenza diminuirà. Se inizi dal cuore del sistema, il rischio di fallimento è talmente alto che darai ragione a chiunque gridi al disastro.

Confronto reale tra approccio ingenuo e approccio esperto

Per capire davvero la differenza, guardiamo come due aziende diverse gestiscono l'integrazione di un nuovo fornitore di spedizioni nel loro sistema e-commerce.

L'azienda A decide di seguire la teoria alla lettera senza esperienza pratica. Il manager ordina di riscrivere l'intero modulo spedizioni. Il team passa quattro settimane a definire interfacce universali, cercando di prevedere ogni possibile variabile di ogni corriere del mondo. Creano una gerarchia di classi complessa, con ereditarietà multipla e pattern complicati. Quando finalmente provano a collegare il nuovo fornitore, scoprono che le API del corriere restituiscono i dati in un formato che la loro bellissima architettura non aveva previsto. Devono ricominciare da capo, aggiungendo "pezze" di codice qua e là, distruggendo tutta l'eleganza iniziale. Il costo finale è di otto settimane di lavoro e un modulo che è un Frankenstein di teoria e hack sporchi.

L'azienda B, guidata da qualcuno che ha già fallito in passato, agisce diversamente. Iniziano implementando l'integrazione nel modo più semplice e brutale possibile, mantenendola però fisicamente separata dal resto dell'ordine. Non cercano di creare l'interfaccia perfetta subito. Aspettano di dover aggiungere un secondo corriere. Solo a quel punto guardano le somiglianze reali, non quelle immaginate. Estraggono la logica comune solo dove è evidente. Se un corriere richiede un dato che l'altro non ha, non complicano l'interfaccia globale, ma gestiscono l'eccezione localmente. Risultato: il primo corriere è attivo in cinque giorni, il secondo in tre. Il codice è meno "accademico" ma infinitamente più facile da gestire perché riflette la realtà del business, non un libro di testo.

L'azienda B ha capito che il valore non sta nel seguire un dogma, ma nel ridurre l'attrito tra il codice e le necessità del mercato. Hanno risparmiato il 70% del tempo rispetto all'azienda A e hanno un sistema che funziona davvero.

L'errore fatale di ignorare il contesto organizzativo

Non puoi implementare un'architettura disaccoppiata in un'azienda con una gerarchia rigida e centralizzata. Esiste un principio noto come Legge di Conway, che suggerisce che le organizzazioni progettano sistemi che rispecchiano la propria struttura di comunicazione. Se la tua azienda richiede cinque firme per approvare un cambiamento di processo, il tuo software finirà per avere colli di bottiglia simili, indipendentemente da quanto cerchi di applicare i principi di Sandi alla tua base di codice.

Ho visto startup cercare di emulare le architetture a microservizi di Netflix quando erano ancora in tre persone in un garage. È follia. La complessità operativa di gestire dieci piccoli servizi indipendenti li ha uccisi prima ancora che potessero lanciare il prodotto. Quando sei piccolo, la comunicazione è veloce e informale; il tuo software dovrebbe riflettere questa agilità, non imitare la complessità di una multinazionale.

D'altra parte, se sei in una grande azienda, il problema è l'opposto. La frammentazione della conoscenza fa sì che nessuno abbia una visione d'insieme. In questo caso, l'isolamento dei componenti è la tua unica ancora di salvezza. Se una modifica in un modulo della contabilità può rompere il portale clienti, significa che non hai un'azienda, hai una bomba a orologeria. In questo contesto, investire tempo per separare le responsabilità non è un lusso, è una strategia di sopravvivenza.

Cosa serve davvero per non buttare soldi

Per avere successo in questo campo, devi smettere di cercare la perfezione e iniziare a cercare la sostenibilità. Non esiste una "soluzione finale". Quello che scrivi oggi sarà il debito tecnico di domani, e va bene così.

1. Accetta il disordine controllato. Non cercare di pulire ogni angolo del tuo sistema. Concentrati sulle aree che cambiano più spesso. Se un modulo funziona da tre anni e non viene mai toccato, lascialo stare, anche se il codice è orribile. Rifarlo sarebbe un pessimo investimento finanziario.
2. Smetti di assumere solo "esecutori". Hai bisogno di persone che sappiano dire di no. Se un programmatore accetta ogni tua richiesta senza discutere l'impatto architettonico, ti sta portando dritto verso un muro di costi di manutenzione insostenibili.
3. Quantifica il costo del ritardo. Prima di iniziare una grande ristrutturazione, chiediti: "Quanto ci costa restare come siamo per altri sei mesi?". Se la risposta è meno del costo della ristrutturazione, allora rimanda.

La verità è che la maggior parte delle persone fallisce perché tratta la tecnologia come una religione invece che come uno strumento finanziario. Ogni riga di codice è una passività, non un asset. Più ne scrivi, più ne devi mantenere. Il vero esperto è quello che riesce a ottenere il massimo risultato col minimo numero di astrazioni possibili.

Non aspettarti che questo percorso sia indolore. Sarà frustrante, costoso e spesso ti sembrerà di tornare indietro. Ma se riesci a superare la fase dell'entusiasmo ingenuo e ad affrontare i problemi con pragmatismo cinico, allora inizierai a vedere i benefici reali in termini di stabilità e velocità di mercato. Non cercare scorciatoie, perché in questo settore la strada più breve è quasi sempre quella che ti porta a fallire più velocemente. Il successo non arriva da un'illuminazione improvvisa, ma dalla gestione metodica e noiosa di centinaia di piccoli errori quotidiani.