SUPERCAT.DEV

Nel mondo dello sviluppo software c’è una tentazione ricorrente: progettare subito il sistema “ideale”. Quello ben fattorizzato, elegantemente distribuito, scalabile quasi all’infinito, pieno di componenti specializzati e pronto per qualsiasi scenario futuro.

Sulla carta sembra la scelta più matura. Nella pratica, molto spesso è il modo più rapido per complicarsi la vita.

Sean Goedecke, in un articolo pubblicato a fine agosto 2025, propone un principio tanto semplice quanto potente: quando progetti un sistema, fai la cosa più semplice che possa davvero funzionare. Non la più raffinata. Non la più futuribile. Non quella che impressiona di più in un diagramma con scatole e frecce. Quella che risolve il problema reale di oggi con il minor numero possibile di pezzi in movimento.

Il bello è che questa idea non vale solo per i nuovi progetti. Vale anche per bug fixing, manutenzione ed evoluzione di sistemi esistenti. Secondo Goedecke, molti ingegneri sbagliano approccio perché cercano di immaginare subito lo stato finale “perfetto” del sistema, invece di capire a fondo il contesto attuale e costruire la risposta più semplice possibile.

La semplicità non è banalità

Uno degli aspetti più interessanti dell’articolo è che smonta un equivoco comune: “semplice” non significa “raffazzonato”.

Anzi, spesso è il contrario.

Una soluzione improvvisata, una pezza, un hack veloce, sembrano scorciatoie. Ma molto spesso introducono nuova complessità cognitiva: eccezioni da ricordare, dipendenze strane, regole implicite, casi speciali. Goedecke osserva che la vera soluzione semplice, quella buona, di solito richiede più comprensione del sistema, non meno. In altre parole: trovare la soluzione più semplice è lavoro di ingegneria, non il suo contrario.

Questo punto è fondamentale. I junior tendono spesso a voler usare tanti strumenti perché finalmente li conoscono: cache distribuite, code, storage dedicati, servizi separati, orchestrazione sofisticata. È normale. Fa sentire “ingegneri veri”. Ma la maturità tecnica arriva quando capisci quando non aggiungere un componente.

Un esempio concreto: il rate limiting

Goedecke fa un esempio molto efficace. Hai un’applicazione Go e vuoi aggiungere del rate limiting. La prima idea potrebbe essere introdurre Redis, memorizzare i contatori per utente e implementare un algoritmo come il leaky bucket. Funzionerebbe. Ma è davvero la cosa più semplice che possa funzionare?

Forse no.

Forse basta memorizzare i contatori in memoria. Oppure il proxy edge che hai già davanti all’applicazione supporta già il rate limiting e puoi configurarlo con poche righe. Solo se questi approcci non soddisfano i requisiti reali — ad esempio perché hai troppe istanze parallele o non puoi perdere stato in caso di riavvio — allora ha senso aggiungere uno storage persistente come Redis.

È un ottimo promemoria per chi sviluppa software tutti i giorni: ogni nuova infrastruttura ha un costo. Deployment, monitoraggio, incidenti, ambienti di test, manutenzione operativa. La domanda corretta non è “questa tecnologia è potente?”, ma “mi serve davvero adesso?”.

Come si riconosce una soluzione semplice?

Qui l’articolo entra in una zona molto interessante, perché ammette che la semplicità non è sempre ovvia. Goedecke propone due criteri intuitivi.

Il primo: un sistema semplice ha meno pezzi mobili, cioè meno cose da tenere in testa mentre lavori.

Il secondo: un sistema semplice è meno internamente connesso, quindi è composto da elementi con interfacce più chiare e lineari.

Quando questi criteri non bastano, introduce anche uno spareggio utile: una soluzione semplice tende a essere più stabile nel tempo. Se, a requisiti invariati, una delle due opzioni richiede più lavoro continuo, probabilmente non è la più semplice. È per questo che, nel suo esempio, il rate limiting in memoria può risultare più semplice di Redis: meno manutenzione, meno incidenti possibili, meno infrastruttura da trascinarsi dietro.

Il vero bersaglio: l’ossessione per la scala

Un altro punto forte del pezzo è la critica all’over-engineering guidato dalla paura del futuro.

L’autore sostiene che uno dei peccati capitali dell’ingegneria SaaS moderna sia l’ossessione per la scalabilità: progettare oggi per volumi che forse non arriveranno mai, o che comunque si manifesteranno in forme imprevedibili. Secondo lui, nei sistemi non banali non si riesce davvero a prevedere in anticipo dove saranno i colli di bottiglia a diversi ordini di grandezza di traffico. Al massimo ci si può preparare a un incremento ragionevole, come 2x o 5x, e poi osservare il comportamento reale del sistema.

Questo è un messaggio molto attuale. Quante volte vediamo applicazioni piccole o medie costruite come se dovessero servire domani il traffico di Netflix o Amazon? Microservizi prematuri, code ovunque, architetture distribuite difficili da debuggare, consistenza transazionale trasformata in incubo. Tutto per prevenire problemi ipotetici, mentre quelli attuali restano lì, irrisolti.

La semplicità richiede comprensione

La parte più matura del ragionamento, secondo me, è questa: il vero problema non è scegliere tra semplice e complesso. Il vero problema è che spesso progettiamo sistemi senza capire abbastanza bene il sistema stesso.

Goedecke lo dice chiaramente: è già difficile avere una visione accurata di dove si trovi oggi un sistema; prevedere dove sarà tra sei mesi o un anno è ancora più arduo. Per questo la progettazione basata su requisiti ipotetici tende a produrre design peggiori rispetto a quella basata sui bisogni concreti del presente.

In fondo, qui c’è una lezione molto sobria: la buona progettazione non nasce dalla voglia di costruire qualcosa di impressionante, ma dalla capacità di togliere il superfluo.

La mia lettura

Questa filosofia mi piace perché non è un inno alla mediocrità tecnica. È quasi il contrario: è un invito a fare ingegneria vera, separando ciò che è necessario da ciò che è solo seducente.

Fare la cosa più semplice che possa funzionare non vuol dire ignorare il futuro. Vuol dire non pagarlo in anticipo senza sapere se arriverà davvero.

Vuol dire anche accettare che un sistema sano può crescere per passi, invece di nascere già sovradimensionato. E che spesso l’architettura migliore non è quella che mostra più scatole nel diagramma, ma quella che lascia meno sorprese a chi dovrà mantenerla.

Per chi scrive software ogni giorno, forse questa è una delle domande più utili da tenere sulla scrivania:

Sto risolvendo il problema reale di oggi, oppure sto costruendo complessità per un futuro che mi sto solo immaginando?

Fonte: https://www.seangoedecke.com/the-simplest-thing-that-could-possibly-work