Quando la semplicità imposta diventa semplicismo pericoloso

Le frasi che fanno rabbrividire

Chiunque abbia lavorato nella progettazione di sistemi informatici ha una collezione di perle ascoltate durante le presentazioni al management. Frasi che fanno sorridere, o rabbrividire, per la loro disarmante ovvietà.

“Non ingegnerizziamo troppo” disse un ingegnere di fronte a una semplice architettura client-server, dimenticando evidentemente cosa significhi fare ingegneria.

“Ma dobbiamo fare così tanti microservizi? Non possiamo farne solo due?” verrebbe da chiedersi allora perché mai scegliere un’architettura a microservizi.

“Ma non possiamo usare direttamente il back-end senza passare dal front-end?” certo, e gli utenti scriveranno i dati direttamente nel database con query SQL.

“Perché un database non relazionale, se abbiamo quelli relazionali?” come se la relazionalità fosse una feature aggiuntiva installabile pagando un abbonamento premium.

Queste affermazioni non sono casi isolati. Rappresentano un problema sistemico: la difficoltà del management non tecnico di distinguere tra complessità necessaria e complicazione superflua. E questa incapacità ha conseguenze devastanti sulla qualità dei progetti IT.

Il principio KISS trasformato in semplicismo

Il principio KISS (Keep It Simple, Stupid) è uno dei mantra più citati nello sviluppo software. Il problema è che viene costantemente frainteso come “Keep It Stupidly Simple”. C’è una differenza notevole tra semplificare qualcosa e renderlo semplicistico.

La vera semplicità richiede lavoro e competenza. Significa progettare un sistema che nasconda la complessità necessaria dietro un’interfaccia pulita e comprensibile. Non significa eliminare componenti essenziali perché “sembrano troppi” su un diagramma.

Semplificare non vuol dire compromettere le funzionalità essenziali del sistema. Significa evitare complicazioni inutili, quelle che sono frutto di una mentalità che premia la complessità solo perché appare ingegneristica o impressionante. Ma distinguere tra necessità e fronzolo richiede competenza tecnica, quella che spesso manca esattamente a chi prende le decisioni finali.

Quando la percezione diventa realtà

Ecco la scena tipica: hai passato settimane a progettare un’architettura elegante e robusta, considerando scalabilità, manutenibilità, sicurezza. Arrivi alla presentazione con il tuo diagramma architetturale, orgoglioso del lavoro svolto.

Qualunque architettura tu abbia progettato dovrà passare al vaglio di qualcuno: team leader, dirigente, amministratore delegato. Più si sale nella gerarchia, più diventa improbabile che l’interlocutore colga i dettagli tecnici. Quello che conta è la percezione della complessità.

Più il tuo schema appare complicato, più automaticamente verrà etichettato come costoso e lungo da realizzare, anche se la sostanza potrebbe essere semplice. È un paradosso: non sempre ciò che sembra elaborato è difficile da implementare, così come uno schema con due blocchi non garantisce una soluzione facile.

Agli occhi dei decisori, complessità equivale a costi e tempi maggiori. Non importa quante volte spieghi che quella complessità è necessaria per evitare problemi futuri. Se il diagramma ha più di cinque componenti, è già “troppo ingegnerizzato”.

L’equilibrio impossibile

Il trucco sta nel trovare quel delicato equilibrio tra un design sufficientemente articolato da coprire tutte le esigenze e una semplicità tale da far dire a chi non ha voglia di addentrarsi nei dettagli tecnici: “Il progetto deve essere semplice!”

Ma dove si trova il giusto confine tra una progettazione sufficientemente sofisticata e una eccessiva complicazione che rende il progetto irriconoscibile agli occhi dei decisori? Questa è una lezione che non si apprende da un manuale, né in un corso universitario, ma solo attraverso l’esperienza sul campo, confrontandosi con innumerevoli architetture e i relativi problemi che ne derivano.

L’esperienza ti insegna che ogni freccia in più nel tuo diagramma deve guadagnarsi il diritto di esistere. Ogni componente aggiuntivo deve portare un valore che supera il costo della sua complessità. È un’arte sottile, raffinata attraverso anni di progetti, bug, deploy falliti e notti insonni a chiedersi “Perché ho pensato che fosse una buona idea?”

L’arte della presentazione strategica

Quando si tratta di presentare un progetto, è fondamentale ricordare che la semplicità, se ben dosata, è la chiave del successo. Mentre i tecnici possono apprezzare la ricchezza dei dettagli e la logica sottostante, a livelli decisionali più alti l’unica variabile che conta è quella percepita.

Se il tuo interlocutore è un incompetente in materia tecnica, o se il suo focus è esclusivamente sulla semplicità apparente, il tuo progetto deve risultare limpido e diretto, senza fronzoli che possano essere interpretati come complicazioni inutili. Solo così potrai superare le barriere del gergo tecnico e far comprendere che, in fondo, la vera ingegneria sta nel saper dosare la complessità per ottenere soluzioni efficaci e sostenibili.

Questo non significa mentire o nascondere informazioni critiche. Significa presentare l’informazione in modo che sia comprensibile al tuo pubblico. Un diagramma ad alto livello per il board, i dettagli implementativi per il team tecnico. Diversi livelli di astrazione per diversi stakeholder.

Quando la perfezione diventa il nemico del bene

La ricerca della perfezione tecnica può effettivamente diventare un problema quando si trasforma in perfezionismo fine a sé stesso. Esiste un punto in cui l’aggiunta di ulteriori layer di astrazione, pattern architetturali o microservizi non porta più valore reale al progetto, ma serve solo a soddisfare l’ego tecnico del progettista.

Un microservizio dedicato esclusivamente alla validazione di una data è probabilmente eccessivo. Tre layer di cache dove uno basterebbe è probabilmente eccessivo. Un’architettura a eventi complessa per gestire un flusso lineare è probabilmente eccessiva.

Il problema è che distinguere tra necessità e eccesso richiede esperienza e giudizio, due qualità che non sempre sono presenti nelle persone che prendono le decisioni finali. E così ci si ritrova in situazioni paradossali: progetti legittimamente complessi vengono semplificati fino a diventare disfunzionali, mentre progetti semplicistici vengono approvati perché “hanno solo tre componenti nel diagramma”.

Il prezzo dell’incomprensione

L’eterna lotta tra la complessità necessaria e la semplicità imposta dall’alto continua in ogni presentazione, in ogni revisione architetturale, in ogni meeting tecnico dove sono presenti non tecnici. Più cerchi di entrare nei dettagli, più vedi gli occhi del tuo interlocutore assumere quell’espressione vitrea che conosci fin troppo bene.

Nel frattempo, continueremo a sorridere pazientemente mentre qualcuno suggerisce di “usare direttamente il backend senza frontend”, cercando di spiegare per l’ennesima volta che no, gli utenti non possono scrivere query SQL per inserire i loro ordini.

La vera sfida non è progettare sistemi complessi. Quella è la parte facile. La vera sfida è progettare sistemi che siano sufficientemente sofisticati da funzionare bene, ma abbastanza semplici da essere compresi (o almeno non rifiutati istintivamente) da chi firma i budget.

E forse, solo forse, un giorno arriveremo a un mondo dove le decisioni tecniche vengono prese basandosi sulla competenza tecnica piuttosto che su quanto “complicato” appare un diagramma a blocchi.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo