John Ousterhout: progettazione pratica, Tcl e il costo della complessità

Perché il messaggio di Ousterhout conta ancora

John Ousterhout è uno scienziato informatico e ingegnere il cui lavoro attraversa sia la ricerca sia sistemi reali. Ha creato il linguaggio Tcl, ha contribuito a plasmare file system moderni e in seguito ha distillato decenni di esperienza in un'affermazione semplice, leggermente scomoda: la complessità è il nemico principale del software.

Questo messaggio è ancora attuale perché la maggior parte dei team non fallisce per mancanza di funzionalità o impegno—fallisce perché i loro sistemi (e le organizzazioni) diventano difficili da capire, difficili da modificare e facili da rompere. La complessità non rallenta solo gli ingegneri. Si infiltra nelle decisioni di prodotto, nella certezza della roadmap, nella fiducia dei clienti, nella frequenza degli incidenti e persino nel reclutamento—perché l'onboarding diventa un'odissea di mesi.

Il tema centrale: la complessità tassa tutto

L'inquadramento di Ousterhout è pratico: quando un sistema accumula casi speciali, eccezioni, dipendenze nascoste e "sistemi fatti così una volta", il costo non si limita al codice. L'intero prodotto diventa più costoso da far evolvere. Le funzionalità richiedono più tempo, il QA diventa più difficile, i rilasci più rischiosi e i team iniziano a evitare miglioramenti perché toccare qualsiasi cosa sembra pericoloso.

Questo non è un appello alla purezza accademica. È un promemoria che ogni scorciatoia ha pagamenti di interessi—e la complessità è il debito a tasso più alto.

Tre prospettive che useremo in questo articolo

Per rendere l'idea concreta (e non solo motivazionale), guarderemo al messaggio di Ousterhout attraverso tre angoli:

• L'eredità di Tcl: cosa Tcl ha fatto bene riguardo semplicità, composizione e “collante”, e perché queste idee si sono diffuse molto oltre il linguaggio.
• La connessione con Brooks: come "No Silver Bullet" si relaziona alla visione di Ousterhout, dove sono d'accordo e cosa l'area di disaccordo insegna ai team che devono consegnare.
• Regole pratiche di design: in particolare i “moduli profondi” e tecniche di progettazione API che riducono il carico cognitivo per la prossima persona che deve modificare il sistema (che di solito sei tu).

Cosa puoi aspettarti di portare via

Questo non è scritto solo per gli appassionati di linguaggi. Se costruisci prodotti, guidi team o prendi compromessi di roadmap, troverai modi azionabili per individuare la complessità presto, impedirne l'istituzionalizzazione e trattare la semplicità come un vincolo di primo piano—non come un optional dopo il lancio.

Cosa significa davvero “complessità” nei team quotidiani

La complessità non è “tanto codice” o “matematica difficile”. È il divario tra quello che pensi che il sistema farà quando lo cambi e quello che fa davvero. Un sistema è complesso quando piccole modifiche sembrano rischiose—perché non puoi prevedere il raggio d'azione.

Come la complessità si manifesta nel lavoro di tutti i giorni

Nel codice sano, puoi rispondere: “Se cambiamo questo, cos'altro potrebbe rompersi?” La complessità è ciò che rende quella domanda costosa.

Si nasconde spesso in:

• Dipendenze nascoste: una funzionalità si appoggia silenziosamente a una colonna del database, a un job in background o a un flag di configurazione che non è ovvio nel codice che stai modificando.
• Casi speciali: “tranne per i clienti enterprise”, “tranne quando l'utente si è registrato prima del 2021”, “tranne se la richiesta è arrivata da mobile”. Queste eccezioni si accumulano finché il “percorso normale” non è più chiaro.
• Proprietà poco chiara: nessuno si sente responsabile di un'area, quindi le correzioni diventano patch caute invece di miglioramenti netti. Col tempo la strada più sicura diventa “aggiungi un'altra soluzione tampone”.

Il costo: velocità, qualità e fiducia

I team percepiscono la complessità come ritardo nelle consegne (più tempo speso a investigare), più bug (perché il comportamento è sorprendente) e sistemi fragili (le modifiche richiedono coordinamento tra molte persone e servizi). Mette anche sotto sforzo l'onboarding: i nuovi arrivati non riescono a costruire un modello mentale, quindi evitano i flussi core.

Complessità essenziale vs accidentale

Parte della complessità è essenziale: regole di business, requisiti di conformità, casi limite del mondo reale. Non puoi cancellarla.

Ma molta è accidentale: API confuse, logica duplicata, flag “temporanei” che diventano permanenti e moduli che perdono dettagli interni. Questa è la complessità che le scelte di design creano—e l'unica che puoi ridurre con costanza.

L'eredità di Tcl: le buone idee che si sono diffuse

Tcl è nato con un obiettivo pratico: rendere facile automatizzare software e estendere applicazioni esistenti senza riscriverle. John Ousterhout lo ha progettato affinché i team potessero aggiungere “la programmabilità necessaria” a uno strumento—poi consegnare quel potere a utenti, operatori, QA o chiunque dovesse scriptingare workflow.

L'idea del “linguaggio collante”

Tcl ha reso popolare la nozione di linguaggio collante: uno strato di scripting piccolo e flessibile che connette componenti scritti in linguaggi più veloci e a basso livello. Invece di costruire ogni funzionalità in un monolite, potevi esporre un set di comandi e poi comporli in nuovi comportamenti.

Quel modello si è dimostrato influente perché corrispondeva a come il lavoro avviene davvero. Le persone non costruiscono solo prodotti; costruiscono sistemi di build, harness di test, strumenti admin, convertitori di dati e automazioni una tantum. Uno strato di scripting leggero trasforma quei compiti da “apri un ticket” a “scrivi uno script”.

Cosa Tcl aveva azzeccato (e cosa si è diffuso ovunque)

Tcl ha reso l'embed una preoccupazione di primo piano. Potevi inserire un interprete in un'applicazione, esportare un'interfaccia di comandi pulita e ottenere immediatamente configurabilità e iterazione rapida.

Lo stesso schema riappare oggi in sistemi di plugin, linguaggi di configurazione, API di estensione e runtime di scripting embedded—sia che la sintassi sembri Tcl o no.

Ha anche rinforzato un'abitudine di design importante: separare primitive stabili (le capacità core dell'app host) dalla composizione modificabile (gli script). Quando funziona, gli strumenti evolvono più in fretta senza destabilizzare continuamente il core.

Limitazioni e perché la popolarità è diminuita

La sintassi di Tcl e il modello “tutto è una stringa” potevano risultare controintuitivi, e grandi codebase Tcl diventavano a volte difficili da comprendere senza convenzioni forti. Con l'arrivo di ecosistemi più nuovi con librerie standard più ricche, tooling migliore e community più grandi, molti team sono passati altrove.

Niente di ciò cancella l'eredità di Tcl: ha normalizzato l'idea che estendibilità e automazione non sono extra—sono funzionalità di prodotto che possono ridurre drasticamente la complessità per chi usa e mantiene il sistema.

Lezione di design nascosta nella filosofia di Tcl

Tcl è stato costruito attorno a un'idea apparentemente rigorosa: tenere il core piccolo, rendere la composizione potente e mantenere gli script leggibili abbastanza perché le persone possano collaborare senza traduzioni continue.

Un core piccolo che incoraggia la composizione

Invece di fornire un enorme set di funzionalità specializzate, Tcl puntava su un compatto set di primitive (stringhe, comandi, semplici regole di valutazione) e si aspettava che gli utenti le combinassero.

Quella filosofia spinge i progettisti verso meno concetti, riutilizzati in molti contesti. La lezione per prodotto e progettazione API è semplice: se puoi risolvere dieci bisogni con due o tre building block coerenti, riduci la superficie che le persone devono imparare.

“Semplice da usare” vs “semplice da implementare”

Una trappola è ottimizzare per la comodità di chi costruisce. Una funzione può essere facile da implementare (copia un'opzione esistente, aggiungi un flag speciale, patcha un caso limite) ma rendere il prodotto più difficile da usare.

L'enfasi di Tcl era l'opposto: mantenere il modello mentale stretto, anche se l'implementazione deve fare più lavoro dietro le quinte.

Quando valuti una proposta, chiedi: questo riduce il numero di concetti che l'utente deve ricordare, o ne aggiunge uno in più?

Le primitive piccole possono essere rassicuranti—o pericolosamente taglienti

Il minimalismo aiuta solo quando le primitive sono coerenti. Se due comandi sembrano simili ma si comportano diversamente nei casi limite, gli utenti finiranno a memorizzare trivia. Un piccolo set di strumenti può diventare “spigoli vivi” quando le regole variano sottilmente.

Componibilità vs feature monouso (versione non tecnica)

Pensa a una cucina: un buon coltello, una padella e un forno ti permettono di preparare molti piatti combinando tecniche. Un gadget che affetta solo avocado è un feature monouso: facile da vendere, ma ingombra i cassetti.

La filosofia di Tcl spinge per coltello e padella: strumenti generali che si compongono bene, così non serve un nuovo gadget per ogni ricetta.

Brooks in una pagina: “No Silver Bullet” e la sua tesi

Nel 1986 Fred Brooks scrisse un saggio con una conclusione intenzionalmente provocatoria: non esiste una singola svolta—nessuna “silver bullet”—che renderà lo sviluppo software un ordine di grandezza più veloce, economico e affidabile in un solo colpo.

Il punto non era che il progresso sia impossibile. Era che il software è già un medium dove possiamo fare quasi tutto, e quella libertà porta un onere unico: stiamo definendo continuamente la cosa mentre la costruiamo. Strumenti migliori aiutano, ma non cancellano la parte più dura del lavoro.

Complessità essenziale vs accidentale

Brooks divide la complessità in due categorie:

• Complessità essenziale: difficoltà che deriva dal problema stesso—regole del mondo reale, casi limite e obiettivi contrastanti che il software deve rappresentare.
• Complessità accidentale: difficoltà create dai nostri metodi e strumenti—linguaggi scomodi, pipeline di build goffe, deploy manuali o architetture che ti costringono a pensare troppe cose insieme.

Gli strumenti possono schiacciare la complessità accidentale. Pensate ai guadagni ottenuti da linguaggi di alto livello, controllo versione, CI, container, database gestiti e buoni IDE. Ma Brooks sosteneva che la complessità essenziale domina, e non scompare solo perché il tooling migliora.

Perché conta ancora

Anche con le piattaforme moderne, i team spendono ancora la maggior parte dell'energia a negoziare requisiti, integrare sistemi, gestire eccezioni e mantenere comportamento coerente nel tempo. La superficie può cambiare (API cloud invece di driver di dispositivo), ma la sfida fondamentale resta: tradurre bisogni umani in comportamenti precisi e manutenibili.

Questo crea la tensione su cui si concentra Ousterhout: se la complessità essenziale non si può eliminare, può un design disciplinato ridurre in modo significativo quanto di essa trapela nel codice—e nelle teste degli sviluppatori giorno dopo giorno?

Il “dibattito” Ousterhout vs Brooks, senza clamore

La gente a volte dipinge “Ousterhout vs Brooks” come una lotta tra ottimismo e realismo. È più utile leggerla come due ingegneri esperti che descrivono parti diverse dello stesso problema.

Il contrappunto di Ousterhout: il design compra più di quanto pensi

Brooks dice che non esiste una singola svolta che elimini la parte dura del software. Ousterhout non lo contesta davvero.

La sua obiezione è più circoscritta e pratica: i team spesso trattano la complessità come inevitabile quando molta di essa è auto-inflitta.

Nella visione di Ousterhout, un buon design può ridurre la complessità in modo significativo—non rendendo il software “facile”, ma rendendolo meno confuso da cambiare. È una grande affermazione, e conta perché la confusione è ciò che trasforma il lavoro quotidiano in lavoro lento.

L'avvertimento di Brooks: parte della complessità è intrinseca

Brooks punta sulla difficoltà essenziale: il software deve modellare realtà disordinate, requisiti che cambiano e casi limite esterni al codice. Anche con ottimi strumenti e persone brillanti, non puoi cancellarlo. Puoi solo gestirlo.

Dove sono d'accordo

Le sovrapposizioni sono maggiori di quanto suggerisca il dibattito:

• Parte della complessità è inevitabile perché il mondo è complicato.
• Gran parte del dolore deriva dalla complessità accidentale—dettagli ed eccezioni che non dovrebbero esistere.
• Il costo reale appare dopo: iterazione più lenta, rischio maggiore e aree “non toccare”.

La domanda pratica per i team

Invece di chiedersi “Chi ha ragione?”, chiediti: Quale complessità possiamo controllare questo trimestre?

I team non possono controllare i cambiamenti di mercato o la difficoltà intrinseca del dominio. Ma possono decidere se le nuove feature aggiungono casi speciali, se le API obbligano i chiamanti a ricordare regole nascoste e se i moduli nascondono o perdono complessità.

Questo è il terreno d'azione: accetta la complessità essenziale e sii implacabile nel limitare quella accidentale.

Deep modules: nascondere la complessità nel modo giusto

Un deep module è un componente che fa molto, esponendo però un'interfaccia piccola e facile da capire. La “profondità” è quanto complesso il modulo si prende carico: i chiamanti non devono conoscere i dettagli sgradevoli e l'interfaccia non li forza a farlo.

Un shallow module è l'opposto: può avvolgere una piccola logica, ma spinge la complessità all'esterno—con molti parametri, flag speciali, ordine di chiamata richiesto o regole “devi ricordare di…”.

Deep vs shallow: un'analogia reale

Pensa a un ristorante. Un deep module è la cucina: ordini “pasta” da un menu semplice e non ti interessa chi fornisce gli ingredienti, i tempi di cottura o l'impiattamento.

Un shallow module è una “cucina” che ti dà ingredienti crudi con una scheda di 12 passi e ti chiede di portare la tua padella. Il lavoro si fa lo stesso—ma è stato trasferito al cliente.

Quando aggiungere livelli aiuta (e quando fa male)

Gli strati in più possono essere utili se collassano molte decisioni in una scelta ovvia.

Per esempio, un layer di storage che espone save(order) e gestisce internamente retry, serializzazione e indicizzazione è profondo.

Gli strati fanno danno quando rinominano soprattutto le cose o aggiungono opzioni. Se una nuova astrazione introduce più configurazione di quanta ne tolga—per esempio save(order, format, retries, timeout, mode, legacyMode)—è probabilmente superficiale. Il codice può sembrare “organizzato”, ma il carico cognitivo si vede in ogni punto di chiamata.

Checklist rapida: individuare moduli superficiali

• L'API ha molti parametri, specialmente booleani come useCache, skipValidation, force, legacy.
• I chiamanti devono seguire una sequenza specifica (“chiama A prima di B”) per evitare bug sottili.
• Il modulo fa trapelare concetti interni (percorsi file, nomi di tabelle, regole di threading) nell'interfaccia.
• La maggior parte delle modifiche richiede di toccare molti punti di chiamata perché l'astrazione non stabilizza il comportamento.
• La documentazione sembra un'etichetta di avvertenza più che una promessa (“Non usare X quando Y a meno che Z”).

I deep module non solo “incapsulano codice”. Incapsulano decisioni.

Progettare API che riducono il carico cognitivo

Un'API “buona” non è solo quella che può fare molto. È quella che le persone possono tenere in testa mentre lavorano.

La lente di design di Ousterhout ti spinge a giudicare un'API in base allo sforzo mentale che richiede: quante regole devi ricordare, quante eccezioni prevedere e quanto è facile sbagliare.

Cosa rende un'API amica dell'umano

Le API human-friendly tendono a essere piccole, coerenti e difficili da usare male.

Piccole non significa poco potenti—significa che la superficie è concentrata in pochi concetti che si compongono bene. Coerenti significa che lo stesso pattern funziona in tutto il sistema (parametri, gestione degli errori, naming, tipi di ritorno). Difficili da usare male significa che l'API guida verso percorsi sicuri: invarianti chiare, validazione ai confini e controlli che falliscono presto.

Perché “più opzioni” aumenta i costi per tutti

Ogni flag, modalità o configurazione “per ogni evenienza” diventa una tassa su tutti gli utenti. Anche se solo il 5% dei chiamanti ne ha bisogno, il 100% dei chiamanti deve comunque sapere che esiste, chiedersi se serve e interpretare il comportamento quando interagisce con altre opzioni.

Così le API accumulano complessità nascosta: non in una singola chiamata, ma nella combinatoria.

Default, convenzioni e naming

I default sono una gentilezza: permettono alla maggior parte dei chiamanti di omettere decisioni e ottenere comunque comportamento sensato. Le convenzioni (un modo ovvio per farlo) riducono i rami nella mente dell'utente. Il naming fa un lavoro reale: scegli verbi e sostantivi che rispecchiano l'intento e mantieni operazioni simili con nomi simili.

Un promemoria: le API interne contano tanto quanto quelle pubbliche. La maggior parte della complessità nei prodotti vive dietro le quinte—confini di servizio, librerie condivise e moduli “helper”. Tratta quelle interfacce come prodotti, con review e disciplina di versioning.

Dove la complessità si insinua: fix tattici e casi speciali

La complessità raramente arriva come una singola “brutta decisione”. Si accumula attraverso piccole patch sensate—soprattutto quando i team sono sotto pressione e l'obiettivo immediato è consegnare.

Trappole comuni che si sommano silenziosamente

Una trappola è feature flag ovunque. I flag servono per rollout sicuri, ma quando restano, ogni flag moltiplica i comportamenti possibili. Gli ingegneri smettono di ragionare sul “sistema” e iniziano a ragionare sul “sistema, tranne quando il flag A è attivo e l'utente è nel segmento B”.

Un'altra è la logica per casi speciali: “i clienti enterprise necessitano X”, “eccetto nella regione Y”, “a meno che l'account non abbia più di 90 giorni”. Queste eccezioni spesso si diffondono nel codice e dopo qualche mese nessuno sa più quali siano ancora necessarie.

Una terza è astrazioni che perdono. Un'API che costringe i chiamanti a capire dettagli interni (timing, formato di storage, regole di caching) spinge la complessità all'esterno. Invece di un modulo che si prende l'onere, ogni chiamante impara le stranezze.

Programmazione tattica vs strategica (versione in parole semplici)

Programmazione tattica ottimizza per questa settimana: fix rapidi, cambi minimi, “patcha e vai”.

Programmazione strategica ottimizza per l'anno prossimo: piccoli riprogettamenti che prevengono la stessa classe di bug e riducono il lavoro futuro.

Il pericolo è l’“interesse di manutenzione”. Una soluzione rapida sembra economica ora, ma la paghi con interessi: onboarding più lento, rilasci fragili e uno sviluppo guidato dalla paura in cui nessuno vuole toccare il codice vecchio.

Semplici guardrail che aiutano davvero

Aggiungi prompt leggeri alla code review: “Questo aggiunge un nuovo caso speciale?” “L'API può nascondere questo dettaglio?” “Quale complessità stiamo lasciando dietro di noi?”

Tieni piccoli registri di decisione per i tradeoff non banali (qualche punto è sufficiente). E riserva un piccolo budget di refactor in ogni sprint così le correzioni strategiche non siano considerate lavoro extra.

Perché la complessità uccide prodotti, non solo codebase

La complessità non resta intrappolata nell'ingegneria. Si perde nei tempi, nell'affidabilità e nell'esperienza che i clienti vivono del prodotto.

Costi a livello di prodotto: velocità, stabilità e onboarding

Quando un sistema è difficile da comprendere, ogni cambiamento richiede più tempo. Il time-to-market slitta perché ogni rilascio richiede più coordinazione, più test di regressione e più cicli “per sicurezza”.

L'affidabilità soffre. I sistemi complessi generano interazioni che nessuno può prevedere completamente, quindi i bug emergono come casi limite: il checkout fallisce solo quando coupon, carrello salvato e regola fiscale regionale si combinano in un certo modo. Questi sono gli incidenti più difficili da riprodurre e più lenti da risolvere.

L'onboarding diventa un freno nascosto. I nuovi non riescono a costruire un modello mentale utile, evitano le aree rischiose, copiano pattern che non comprendono e aggiungono involontariamente altra complessità.

La complessità si manifesta come confusione del cliente

I clienti non si preoccupano se un comportamento è causato da un “caso speciale” nel codice. Lo vivono come incoerenza: impostazioni che non valgono ovunque, flussi che cambiano a seconda di come ci arrivi, feature che funzionano “la maggior parte delle volte”.

La fiducia cala, il churn aumenta e l'adozione si arresta.

La tassa della complessità su support e operations

I team di support pagano la complessità con ticket più lunghi e più scambi per raccogliere contesto. Operations paga con più alert, più runbook e deployment più cauti. Ogni eccezione diventa qualcosa da monitorare, documentare e spiegare.

Esempio pratico: un'altra feature vs flussi più semplici

Immagina la richiesta di “un'altra regola di notifica”. Aggiungerla sembra veloce, ma introduce un nuovo ramo di comportamento, più testo nell'UI, più casi di test e più modi in cui gli utenti possono configurarsi male.

Ora confrontalo con semplificare il flusso di notifiche esistente: meno tipi di regole, default più chiari e comportamento coerente su web e mobile. Potresti rilasciare meno manopole, ma riduci le sorprese—rendendo il prodotto più facile da usare, più facile da supportare e più veloce da far evolvere.

Come gestire la complessità come vincolo di prodotto di primo piano

Tratta la complessità come performance o sicurezza: pianificala, misurala e proteggila. Se te ne accorgi solo quando la delivery rallenta, stai già pagando interessi.

Metti un “budget di complessità” in roadmap

Insieme allo scope delle feature, definisci quanto nuova complessità una release può introdurre. Il budget può essere semplice: “niente concetti netti nuovi a meno che non ne rimuoviamo uno” o “qualsiasi nuova integrazione deve sostituire un percorso vecchio”.

Rendi espliciti i tradeoff nella pianificazione: se una feature richiede tre nuove modalità di configurazione e due eccezioni, dovrebbe “costare” più di una che si inserisce nei concetti esistenti.

Usa metriche leggere che i team possano davvero mantenere

Non servono numeri perfetti—solo segnali che mostrino una tendenza:

• Superficie del modulo: numero di metodi pubblici/endpoint, flag o campi di configurazione esposti.
• Conteggio di concetti: quante idee un utente (o un nuovo ingegnere) deve imparare per avere successo.
• Tasso di fallimento delle modifiche: quante volte i deploy richiedono rollback, hotfix o lavoro urgente.

Monitora queste per release e collega le decisioni: “Abbiamo aggiunto due nuove opzioni pubbliche; cosa abbiamo rimosso o semplificato per compensare?”

Prototipa per testare la semplicità, non solo la fattibilità

I prototipi sono spesso giudicati su “Riusciamo a costruirlo?” Invece, usali per rispondere: “Questo sembra semplice da usare e difficile da usare male?”

Fai svolgere a qualcuno che non conosce la feature un compito realistico con il prototipo. misura il tempo per riuscirci, le domande poste e dove sbagliano assunzioni. Questi sono i punti caldi della complessità.

Qui entra anche il valore dei moderni workflow di build—se mantengono l'iterazione stretta e permettono un facile rollback. Per esempio, quando i team usano una piattaforma di vibe-coding come Koder.ai per abbozzare uno strumento interno o un nuovo flusso via chat, funzionalità come planning mode (per chiarire l'intento prima della generazione) e snapshots/rollback (per annullare cambi rischiosi rapidamente) possono rendere la sperimentazione iniziale più sicura—senza impegnarsi in una pila di astrazioni a metà. Se il prototipo passa, puoi esportare il codice sorgente e applicare la stessa disciplina di “deep module” e progettazione API descritta sopra.

Programma pulizie di complessità con criteri di successo chiari

Rendi il lavoro di “cleanup della complessità” periodico (ogni trimestre o a ogni major release) e definisci cosa significa “finito”:

• Rimuovere un'opzione o un caso speciale (non solo rifattorizzare).
• Ridurre i passaggi di onboarding o la configurazione richiesta.
• Unire due API sovrapposte in una sola.
• Migliorare il tasso di fallimento delle modifiche in un'area mirata.

L'obiettivo non è codice più pulito in astratto—ma meno concetti, meno eccezioni e cambiamenti più sicuri.

Azioni pratiche per i team questo trimestre

Ecco alcune mosse che traducono l'idea di Ousterhout “la complessità è il nemico” in abitudini settimanali del team.

5–7 takeaway sintetici

• Tratta la complessità come centro di costo: se non porta valore utente, necessita approvazione di budget.
• Preferisci pochi moduli profondi piuttosto che molti strati sottili che perdono dettagli.
• Mira a interfacce che si spiegano da sole: buoni nomi, superficie ridotta, invarianti chiare.
• Non “aggiungere un'opzione” alla leggera. Le opzioni moltiplicano le interazioni; i casi speciali si compongono nel tempo.
• Se una correzione richiede conoscenza da parte del chiamante, probabilmente hai spostato la complessità fuori dal modulo.
• Considera la cancellazione come metrica di successo: rimuovere codice e casi è spesso il lavoro di design più efficace.

Un piano d'azione breve (1–2 settimane)

Scegli un sottosistema che crea spesso confusione (onboarding doloroso, bug ricorrenti, molte domande “come funziona?”).

1. Mappa l'interfaccia: elenca funzioni pubbliche/endpoint/flag di config e cosa i chiamanti devono sapere.
2. Semplifica il contratto: consolida parametri, elimina flag “mode” e scrivi 2–3 invarianti garantite dal modulo.
3. Elimina i casi speciali: rimuovi i rami aggiunti per un cliente, un ambiente o un bug storico—poi sostituisci con una regola generale.
4. Aggiungi un semplice gate: nuovi flag ed eccezioni richiedono una breve nota di design e un revisore che chieda “Possiamo evitare il caso speciale?”

Letture e seguiti consigliati

• John Ousterhout, A Philosophy of Software Design
• Fred Brooks, “No Silver Bullet”
• Fred Brooks, The Mythical Man-Month (in particolare su integrità concettuale)

Seguiti interni che puoi avviare: una “complexity review” nella pianificazione (testo visibile: /blog/complexity-review) e un controllo rapido per verificare se il tooling sta riducendo la complessità accidentale invece di aggiungere strati (testo visibile: /pricing).

Quale pezzo di complessità rimuoveresti per primo se potessi cancellare un solo caso speciale questa settimana?