Scrivere software è un atto che, in apparenza, chiunque può compiere. Ci si siede, si accende un computer, si apre un IDE, un editor, VI se hai il cuore puro o qualsiasi altra cosa (sì, vale anche Notepad) e si inizia a digitare.
Non servono nemmeno specifiche dettagliate: a cosa servono quando hai tutto in testa? A volte basta un’idea e la voglia di raggiungere un risultato. E qualcosa, inevitabilmente, accade.
Il primo “Hello World” è sempre un momento magico, ma è solo l’inizio.
Superato il primo ostacolo, si scopre che scrivere software è un processo continuo di apprendimento e adattamento. Anche se all’inizio è complicato, con il tempo si imparano i rudimenti: framework, librerie, design pattern. Si capisce come strutturare il codice, come modularizzarlo, come testarlo. E alla fine, dopo giorni o settimane di lavoro, si ottiene qualcosa che funziona—magari non esattamente come l’avevamo in testa, ma funziona: e in quel momento è un’esplosione di adrenalina e soddisfazione.
Anche i più pessimisti, quelli che fanno fatica a chiedere persino alla madre un bicchier d’acqua, dopo ore, giorni e settimane trovano sempre una soluzione.
Un tempo c’erano gli amici, poi sono arrivati i forum. Oggi possiamo persino affidarci a un’intelligenza artificiale o a un agente: scriviamo la nostra idea, anche sgrammaticata, e inizia la magia.
Ma oggi non voglio parlare di questo. Lasciamo stare per una volta l’aspetto romantico della programmazione, la credenza popolare che basti mettere le mani su una tastiera per fare cose incredibili, e non parliamo di come si costruisce il software o di come si arriva a un risultato—il mondo è pieno di corsi e manuali.
Quello di cui vorrei parlare oggi è uno degli aspetti più complessi e meno discussi della programmazione: il coraggio di rimuovere del codice.
La vera sfida non è un programma che funziona
Il risultato è solo il primo gradino della costruzione di un software. Qualsiasi programmatore, più o meno convinto dei propri mezzi, dirà sempre di poterci riuscire. Magari mentirà un po’ sui tempi o sugli obiettivi reali, ma la sua risposta sarà sempre: “Ce la faccio”. (Escludo da questo gruppo i pessimisti cronici che partono dicendo “è impossibile”; quelli li scarteremo per praticità).
La vera sfida non è quindi consegnare un programma funzionante. La vera sfida è non farsi sopraffare dal proprio software: non perderne il controllo, non trasformare un banale servizio REST di 10 righe in un mostro mangia-disco (e parlo per esperienza personale).
La crescita del software è entropia e il lavoro del programmatore esperto è combattere questa entropia.Spesso il codice viene paragonato a un asset, quando in realtà è una liability. Se ragioniamo pensando che il codice che scriviamo sia un patrimonio, perdiamo l’aspetto più fondamentale di tutto il processo di creazione: quando scriviamo del codice stiamo creando un debito. Ogni riga di codice deve essere letta, capita, mantenuta, testata e, un giorno, aggiornata o rimossa.
Meno codice c’è, minore è la superficie di attacco per i bug e minore è il costo di manutenzione.
Questa cosa viene spesso sottovalutata, specialmente in contesti aziendali dove il focus è sul “consegnare funzionalità” piuttosto che sul “mantenere un codice sano e gestibile”.
Chi invece lavora per aziende di prodotto illuminate dovrebbe sapere quanto è importante anche la manutenzione, la rimozione del codice obsoleto, la gestione delle dipendenze. Perché un software non è mai “finito”. È un organismo vivente che evolve, cresce, a volte si ammala. Quando manca questa visione, manca una progettualità che prima o poi porterà inevitabilmente al collasso.
Ho avuto la fortuna/sfortuna di seguire entrambe le tipologie di progetti. Alcuni dove c’era un solo obiettivo: consegnare, e che col tempo sono implosi in tonnellate di codice scoordinato; altri in cui era normale fare refactoring continuo, rimuovere codice obsoleto e mantenere una base di codice pulita e mantenibile. La differenza tra i due mondi è abissale.
Siamo tutti accumulatori seriali
Avete presente il programma “Sepolti in casa”? Persone che accumulano oggetti inutili, riempiendo le loro case fino a renderle invivibili. Il software soffre della stessa patologia.
Che lo scriviamo noi o, peggio, che lo faccia un’IA, il codice inizia ad aumentare di volume. Prima poche classi, poche funzioni e pochi script, ma col tempo ci troviamo inondati non solo di codice nostro, ma anche di dipendenze esterne, librerie, moduli, plugin. Ammetto che anche io sono finito più volte in questo gorgo, dato che mi impongo che ogni repository che creo sia self-contained, con tutte le dipendenze necessarie per funzionare—ho visto progetti bloccarsi per la mancanza di una singola libreria.
I VibeCoder che mi leggeranno forse non mi capiranno ancora, ma col tempo si accorgeranno che le IA hanno un obiettivo solo: produrre codice funzionante e, se non lo è, autoconvincersi che lo sia.
L’ultimo obiettivo di un’IA è quello di ottimizzare il codice o ridurne la complessità: questo aspetto non è importante per loro ed è, ad ora, delegato completamente a noi umani. Se gli “umani” non si preoccupano del problema, men che meno se ne preoccuperanno le IA per noi.
È qui che il nostro ruolo cambia radicalmente. Le IA generative sono potenti “fabbriche di aggiunte”, capaci di scrivere migliaia di righe in pochi secondi. Questo sposta il ruolo dell’umano da “scrittore” a “editore” o “curatore”. La nostra abilità più importante diventerà la capacità di validare, semplificare e rifiutare il codice generato dall’IA, non solo di produrlo. Per questo è importante dare una guida agli strumenti basati sul vibe: non basta dire “genera un CRM”, dobbiamo avere in testa l’architettura, le dipendenze, la manutenzione futura e di conseguenza spezzare tutto dando un boccone alla volta in pasto all’IA.
Se volete rendervi conto se siete sul bordo del burrone o in caduta ormai libera, fate una prova: ispezionate la cartella node_modules di un vostro progetto, o quelle create da Maven o NuGet. In un mio progetto abbastanza semplice ho 1 MB di codice mio e 20 MB di node_modules. La sensazione che mi sia scappato di mano è molto alta e sono appena all’inizio del progetto.
Vi siete mai chiesti: “Perché il mio ‘Hello World’ da tre righe richiede 200 MB di dipendenze?”? Se non l’avete mai fatto, fatelo. Scoprirete un mondo nuovo, spesso sottovalutato, che può trasformare un progetto semplice in un incubo di manutenzione.
Chattando con altri programmatori sento spesso frasi come questa:
Non sono passato da Vue 2 a Vue 3 perché ho 18 dipendenze che non posso aggiornare senza riscrivere metà del progetto.Sembra una scusa, ma è una realtà con cui molti sviluppatori si confrontano quotidianamente.
Le dipendenze spesso vengono prese sottogamba: accumuliamo una montagna di funzionalità senza una vera ragione. Si aggiunge, si aggiunge, e poi si aggiunge ancora. È facile aggiungere una funzionalità, specialmente se la richiesta arriva da un cliente o da un product manager. Ma raramente ci si ferma a chiedere: “È davvero necessaria questa funzionalità?” e soprattutto non si torna mai indietro.
Questo fenomeno ha un nome: feature creep.
Feature Creep: il nemico silenzioso
La domanda che dobbiamo farci ogni giorno, quando vediamo una riga di codice ferma da anni, è: “È davvero necessaria?”
La risposta spesso è “no”. Ma agire di fronte a quel “no” è costoso. Spiegarlo a un cliente o a un product manager richiede una giustificazione tecnica e verbale solida, che pochi hanno il coraggio, o la forza, di sostenere.
Il “feature creep” non è solo un problema di codice, ma di prodotto. Un’interfaccia utente con troppi bottoni, opzioni e configurazioni soffre dello stesso problema. Il coraggio di “togliere” si applica anche al Product Manager che dice “no” a una nuova funzionalità per mantenere il prodotto focalizzato e semplice.
Diffidate poi da chi vi dice:
Il problema è il tuo fat client, non le dipendenze che usi.Questo è solo un modo per distogliere l’attenzione dal vero problema: l’accumulo incontrollato di codice e dipendenze. Non è che un’architettura abbia un vantaggio su un’altra—il problema dell’accumulo seriale rimane lo stesso.
Volendo proprio essere pignoli, un fat client potrebbe avere dei vantaggi rispetto a un thin client sezionato in N servizi, dato che rappresenta un unico punto di controllo, rispetto a verificare servizi che sono, virtualmente, utilizzati da un numero incontrollato di client—ma questo è un altro discorso.
Le funzionalità superflue e le dipendenze fuori controllo complicano tutto. Il software diventa fragile, lento, difficile da mantenere. Il debito tecnico cresce in modo invisibile, finché non diventa impossibile ignorarlo.
L’incubo della manutenzione
Finché siamo “con la testa sul progetto” e lavoriamo quotidianamente a feature e refactoring, abbiamo qualche probabilità aggiuntiva di riuscire a gestire il caos. Ma inevitabilmente, se quel progetto viene messo da parte e dopo mesi viene ripreso, o se il team varia molto, l’inevitabile deriva è il caos e l’aumento del debito tecnico.
Più alto è il numero di dipendenze importate, maggiore è il problema dell’obsolescenza trasversale.
Ma con “dipendenze” non pensiamo solo alla libreria X o Y che usiamo per fare il parsing di un file JSON. Pensiamo a tutto l’ecosistema: versioni di linguaggio, librerie, framework, toolchain, sistemi di build, ambienti di esecuzione e via dicendo.
A volte si finisce in un cul-de-sac tecnico: l’aggiornamento che ci serve va in conflitto con un’altra libreria fondamentale, che non è ancora stata aggiornata o il cui manutentore è sparito nel nulla. Poco importa se è open source—anche questo è un concetto sopravvalutato nello sviluppo software.
A quel punto le scelte sono poche: riscrivere parti del software, accettare il buco di sicurezza, o lasciare tutto com’è, sperando che non crolli.
È facile dire “il mio software è perfetto”. Può essere vero per le righe che hai scritto tu—anche se spesso sono solo bias—ma non lo è per l’ecosistema di componenti esterne su cui poggia.
Perché non togliamo?
Ma perché non togliamo? Perché abbiamo paura. Paura di rompere qualcosa (“E se questo codice serviva a quel caso X che non ho testato?”).
Per togliere con coraggio servono due cose fondamentali: sicurezza tecnica e psicologica, ma soprattutto la volontà di farlo.
Serve anche una cultura aziendale che premi la sottrazione.
In molte aziende, la produttività è misurata in “funzionalità consegnate” o “ticket chiusi”. Ma quante volte un programmatore viene lodato per aver rimosso 1000 righe di codice obsoleto? Una “Pull Request” con -1000 righe dovrebbe essere celebrata. Serve una cultura che veda il refactoring e la pulizia non come “lavori di casa”, ma come parte integrante e nobile del processo di sviluppo.
Il coraggio di togliere
I veri programmatori sono quelli capaci di ridurre.
Ken Thompson, co-creatore di Unix e del linguaggio C, disse una volta:
Uno dei miei giorni più produttivi è stato eliminare 1000 righe di codice.Non so quanto questa affermazione sia vera, ma il concetto è potente. La vera maestria non sta nell’aggiungere, ma nel saper togliere senza perdere funzionalità.
C’è anche una frase famosa di Tony Hoare, l’inventore di Quicksort:
Ci sono due modi per progettare software: uno è renderlo così semplice che non ci siano palesemente difetti, l'altro è renderlo così complicato che non ci siano palesi difetti. Il primo metodo è molto più difficile.Come dargli torto? Del resto, la sua laurea in lettere, precedente alla carriera informatica, gli dava forse una marcia in più nel comprendere l’eleganza della semplicità.
Ma visto che non esistono rose senza spine, oltre a questa perla, Hoare ci ha lasciato anche una delle più grandi tragedie dell’informatica moderna: il concetto di “NULL POINTER”. Se vi ha mai rovinato una giornata, ora sapete chi ringraziare.
Only the brave remove stuff
Ma torniamo a noi. Come si fa, concretamente, a togliere?
Il primo passo è rimuovere il codice inutile. Sembra facile, ma è qui che scattano le resistenze, sia strutturali che umane. Per vincere questa battaglia servono armi adeguate:
- Test automatici robusti: una suite di test che dia la fiducia che, se si rimuove qualcosa di essenziale, un test fallirà, proteggendoci da regressioni inaspettate.
- Sicurezza psicologica: un ambiente di lavoro dove “rompere” qualcosa in un ambiente di test o staging non è un crimine, ma parte del processo di apprendimento e pulizia.
- Verifica continua dell’utilizzo: quante feature sono state implementate su richiesta di un cliente che oggi non è più tale? Quante procedure non vengono usate da nessuno? È fondamentale porsi queste domande e agire di conseguenza.
- Affrontare la paura del “e se un giorno servisse?”: questa è la scusa più comune per non cancellare. Spoiler: quel giorno non arriverà quasi mai. E se anche arrivasse, le esigenze saranno cambiate a tal punto che riscrivere il codice da zero sarà comunque l’opzione migliore, piuttosto che adattare una soluzione vecchia e dimenticata. Il codice scritto per una “futura implementazione” è un’ipoteca sul futuro che raramente viene riscattata.
Il passo successivo è semplificare le logiche complesse e ridurre al minimo le dipendenze. Esistono casi virtuosi di software pensati per avere zero o pochissime dipendenze, proprio per facilitare diffusione e manutenzione.
Ogni progetto software che si rispetti dovrebbe dedicare tempo a eliminare e ripulire, come un rituale sacro. Ogni riga di codice è un peso, una responsabilità che ci portiamo dietro. Ogni riga che aggiungiamo è una riga che dovremo mantenere, testare e su cui dovremo fare debug.
Non è un dramma cancellare. Con i sistemi di versionamento come Git, possiamo sempre recuperare ciò che è stato rimosso. Ma la verità è che, nove volte su dieci, quel codice era solo zavorra.
La vera maestria è la semplicità
È facile aggiungere. Tutti sono bravi ad aggiungere. Ma togliere? È lì che si gioca la vera partita.
La maestria di uno sviluppatore senior si misura non tanto da quanto codice sa scrivere, ma da quanto codice sa eliminare preservando le funzionalità essenziali.
Ciò che ci frena è la paura del “non lo tolgo perché forse servirà domani”. Ma quel “domani” non arriva quasi mai. Come afferma il principio YAGNI (You Aren’t Gonna Need It): se non ti serve ora, non implementarlo.
Il vero valore non sta nell’aggiungere, ma nel distillare l’essenziale, eliminare il rumore e costruire qualcosa che funzioni davvero. Questo è il coraggio di togliere. Ed è questo che differenzia un programmatore illuminato da qualcuno che non vede oltre il proprio fine settimana.
