Ridurre la complessità senza ridurre le ambizioni: principi pratici per sistemi più semplici

Perché la complessità non è un traguardo, ma un campanello d’allarme.

La complessità non è competenza: è un avvertimento

Nel nostro settore esiste una strana fascinazione per la complessità.

La si venera, la si giustifica, la si usa come biglietto da visita.

Quasi che creare qualcosa di difficile da capire fosse sinonimo di genialità.

Spoiler: non lo è.

Un sistema complesso non è un’opera d’arte. È un segnale d’allarme, spesso ignorato, che preannuncia rallentamenti, bug, costi crescenti e decisioni sempre più lente. La complessità non fa grande un team: lo immobilizza.

La verità è semplice e farà male a qualcuno:

Scrivere codice complicato è facile. Scrivere codice semplice è un atto di coraggio.

KISS non è uno slogan. È un esame di maturità tecnica

Il principio “Keep It Simple, Stupid” è probabilmente il concetto più citato e meno applicato dell’ingegneria del software.

Molti lo ripetono, pochissimi lo vivono.

Il motivo è scomodo: la semplicità ti mette a nudo. Non puoi nasconderti dietro pattern sovrapposti, astrazioni fragili o architetture ipertrofiche create per scenari che non arriveranno mai. La semplicità richiede chiarezza di obiettivi, competenza reale e la capacità di tagliare ciò che non serve.

È per questo che spesso si preferiscono soluzioni complicate: fanno più scena, più “senior”, più LinkedIn-ready.

Se puoi spiegarla in 30 secondi, è buona. Se ti servono 15 minuti, è probabilmente fumo.

Leggibilità vs trucchi da mago: un conflitto inutile

C’è una tendenza distruttiva nella nostra industria: scambiare la compressione sintattica per eleganza.

One-liner, funzioni che fanno tre cose nascoste, sintassi contratte che “solo noi capiamo” come se “essere indecifrabili” fosse un valore professionale.

Non lo è.

Un codice che non comunica è un codice morto. Un codice che richiede un decodificatore mentale è un atto di ostilità verso il team.

Se un junior non può leggerlo, non è elegante: è stupido.

La leggibilità non è un lusso: è uno degli strumenti più potenti per ridurre la complessità incidentale, quella che nasce non dal problema, ma da come decidiamo di affrontarlo.

Complessità essenziale vs complessità accidentale

Sì, alcuni problemi sono davvero complessi. Il dominio la parte “essenziale” può essere ricco, articolato, difficile.

Ma diciamoci la verità: la maggior parte della complessità presente nei sistemi moderni non deriva dal dominio. È accidentale, auto-inflitta, generata da scelte tecniche sbagliate o affrettate.

E la parte peggiore è che questa complessità non aggiunge valore. Anzi, lo sottrae.

Se il problema è difficile e la soluzione è difficile, non hai risolto nulla. Hai solo creato un altro problema.

YAGNI, anti-pattern e il feticismo dell’astrazione

Viviamo in un’epoca in cui sembra più interessante progettare architetture future per un traffico che non arriverà mai, piuttosto che risolvere i bisogni attuali.

È la malattia del “costruire per sicurezza”, che spesso nasconde insicurezze professionali. O peggio, la paura di essere rimpiazzati.

A volte introduciamo astrazioni non perché servono, ma perché “così sembra più enterprise”.

Non puoi scalare ciò che non hai ancora costruito.

La disciplina del “non fare cose inutili” è la prima difesa contro il debito tecnico. Eppure è una delle meno rispettate.

La semplicità come acceleratore di scaling

C’è una verità controintuitiva che chi costruisce sistemi ad alta complessità fatica ad accettare:

Un sistema semplice scala meglio di un sistema complicato.

Scala meglio tecnicamente, perché è più facile modificarlo, osservarlo, rinforzarlo. Ma scala soprattutto sul piano umano: un team capace di comprendere tutto il sistema può muoversi con una velocità inarrivabile per chi vive immerso nei diagrammi.

Sistemi semplici creano team veloci. Team veloci creano prodotti migliori. Prodotti migliori attraggono clienti. I clienti portano traffico. Il traffico finalmente richiede scaling reale.

La semplicità è un investimento, non un limite.

La complessità come killer culturale

Un’architettura complessa non impatta solo la codebase: impatta le persone.

• Rende più lente le decisioni.
• Aumenta le dipendenze tra team.
• Distrugge l’ownership.
• Rende l’onboarding un percorso a ostacoli.
• Trasforma il debugging in un atto di fede.

Se per capire chi chiamare devi aprire un diagramma di 12 pagine, il problema non è l’organizzazione: è il sistema.

L’over-engineering come forma di insicurezza professionale

Diciamolo apertamente: molta complessità nasce dall’ego.

Alcuni ingegneri costruiscono strutture inutili per dimostrare quanto sono “bravi”. Altri usano la complessità come barriera d’ingresso, come modo per diventare indispensabili. Altri ancora come scusa per ritardare il delivery (“non è ancora abbastanza maturo”).

La semplicità, invece, mette pressione: quando tutto è chiaro e lineare, il risultato si giudica subito.

Lavorare semplice fa paura: chiunque può giudicarti.

Ma è proprio questa trasparenza a creare sistemi realmente sani.

La semplicità si misura

La complessità si nasconde bene. La semplicità, no: è evidente.

Per questo è utile introdurre metriche (anche basilari) che indichino quanto un sistema è comprensibile, mantenibile e modificabile. Non perché servano numeri perfetti, ma perché ciò che misuri può migliorare.

E ciò che rifiuti di misurare, spesso ti sta già danneggiando.

Conclusione: la semplicità non è minimalismo, è responsabilità

Rendere un sistema semplice non è un gesto estetico, né un esercizio filosofico. È un atto di leadership.

Richiede visione, disciplina, capacità di dire no, e soprattutto la consapevolezza che ciò che costruiamo deve vivere nel tempo, nelle mani di altri, sotto pressioni future che oggi non immaginiamo.

La semplicità non riduce le ambizioni: le rende realizzabili.

La complessità è un debito.
La semplicità è un investimento.