C’è un momento preciso, nella vita di chi sviluppa software, in cui capisci che la moto non parte.
Non è una metafora elegante. È proprio quella sensazione lì: premi il bottone, guardi i log, rilanci la pipeline, riavvii il servizio. Niente. Silenzio. O peggio: parte, ma fa un rumore strano. Un errore 500 che compare solo il venerdì alle 18:47. Un job notturno che “ogni tanto” si blocca. Una feature che funziona… finché non la usa qualcuno.
In Lo Zen e l’arte della manutenzione della motocicletta, Pirsig usa la manutenzione come pretesto filosofico. Non parla davvero di carburatori: parla del rapporto tra l’uomo e ciò che costruisce. E la cosa interessante è che, senza nominare una riga di codice, descrive perfettamente la vita di chi si trova davanti a un sistema legacy che nessuno vuole toccare.
La differenza è che noi non lo chiamiamo “manutenzione”. Lo chiamiamo “task tecnico”, “debito”, “hardening”, “miglioria”. Lo chiamiamo in tutti i modi tranne che con il suo nome, perché manutenzione suona come costo. E nel mondo della roadmap il costo è sempre sospetto.
La Qualità non è un KPI
Pirsig introduce il concetto di Qualità come qualcosa che precede la distinzione tra soggetto e oggetto. Non è una metrica, non è un punteggio. È un’esperienza. È quel momento in cui guardi qualcosa e sai che è fatto bene, anche se non hai ancora trovato le parole per dirlo.
Nel software abbiamo provato a tradurre la qualità in numeri. Copertura test, code smell, complessità ciclomatica, SLA, SLO, uptime. Tutte cose utili. Tutte cose che, da sole, non garantiscono nulla.
Un sistema può avere il 90% di copertura e essere ingestibile. Può avere zero bug critici e una struttura talmente fragile che ogni modifica è un terno al lotto. Può avere un’architettura “moderna” e richiedere tre persone e un rito voodoo per cambiare un enum.
La qualità, quella vera, la riconosci quando fai una modifica e non hai paura. Quando leggi una funzione e capisci cosa fa senza dover aprire sei file. Quando il sistema ti accompagna invece di opporsi.
Robert C. Martin, in Clean Code e ancora di più in The Clean Coder, parla di disciplina professionale. Non è estetica. Non è minimalismo per sviluppatori annoiati. È riduzione del dolore futuro. È la scelta di non lasciare trappole.
E qui c’è già un primo punto scomodo: la qualità non è una caratteristica del codice. È una scelta morale del professionista.
Manutenzione: l’attività che tutti vogliono evitare (e che tutti pagano)
Nel libro di Pirsig la manutenzione è attenzione, è comprensione, è rispetto per la macchina. Se odi la moto, è perché non la capisci. Se non la capisci, ogni problema diventa un affronto personale.
Nel software facciamo lo stesso. Il codice “di merda” è sempre quello scritto da qualcun altro. Il legacy è una colpa. Un peso. Un fastidio da aggirare con un rewrite salvifico che, curiosamente, genera nuovo legacy nel giro di 18 mesi.
La verità è più brutale: la manutenzione è il prodotto.
Se un sistema vive più di qualche mese, la maggior parte del tempo speso su quel sistema sarà manutenzione. Correzioni, adattamenti, nuove feature che si incastrano su fondamenta già esistenti. Pensare che il valore sia solo nella “nuova funzionalità” è un’illusione da demo commerciale.
Ogni volta che qualcuno dice “non abbiamo tempo per sistemare questa parte”, sta solo spostando il conto nel futuro. Con interessi. E il futuro, nel software, arriva sempre di venerdì pomeriggio.
Michael Feathers, in Working Effectively with Legacy Code, dice una cosa molto concreta: prima rendi il sistema modificabile, poi lo modifichi. È una frase semplice, ma ribalta la mentalità della feature factory. Perché modificabile significa testabile, leggibile, isolabile. Significa manutenzione come prerequisito, non come ripensamento.
Eppure, nella maggior parte delle organizzazioni, la manutenzione è una concessione. “Facciamo uno sprint tecnico.” Come se fosse una pausa dalla produttività vera. Come se la stabilità non fosse parte del prodotto.
È un po’ come comprare una moto e poi lamentarsi che serve cambiare l’olio.
Romanticismo vs classicismo: la guerra silenziosa nei team
Pirsig distingue tra visione romantica e visione classica.
La romantica è quella dell’esperienza, dell’immediatezza, del “basta che funzioni”. La classica è quella della struttura, della meccanica, del perché.
Nel software questa tensione è quotidiana. Da una parte chi vuole consegnare. Dall’altra chi vuole capire. Da una parte l’entusiasmo della feature. Dall’altra la noia del refactoring.
Il romantico vede la demo che gira. Il classico vede la dipendenza circolare che prima o poi esploderà. Il romantico dice “poi sistemiamo”. Il classico sa che “poi” è un luogo mitologico dove finiscono le buone intenzioni.
La caricatura è facile: l’hacker contro l’architetto, lo startupper contro l’ingegnere enterprise. Ma la realtà è meno teatrale e più pericolosa: quando una delle due visioni domina, la qualità muore.
Se domina il romanticismo, si accumula entropia. Se domina il classicismo, si accumula complessità inutile. Over-engineering, pattern per sport, microservizi per tre utenti. Kafka per spedire due email al giorno.
La qualità sta nel dialogo. Nel sapere quando essere veloci e quando essere lenti. Nel sapere che la velocità senza struttura è solo fretta, e che la struttura senza contesto è solo narcisismo tecnico.
The Pragmatic Programmer lo dice con meno filosofia e più pragmatismo: fai la cosa giusta per il contesto. Non per l’ego. Non per il curriculum. Non per l’ultima moda su LinkedIn.
“Non ho tempo”: l’origine di ogni legacy
Ogni sistema ingestibile nasce da una frase apparentemente innocua: “Non ho tempo.”
Non ho tempo per scrivere test.
Non ho tempo per rinominare quella variabile.
Non ho tempo per separare quella responsabilità.
Non ho tempo per capire davvero come funziona.
Finché tutto regge, quella scelta sembra intelligente. Hai consegnato. Sei stato veloce. Hai fatto “impatto”. Poi un giorno devi cambiare qualcosa di piccolo. E scopri che non è piccolo. È collegato a tutto. È incastrato in un groviglio di assunzioni non documentate.
A quel punto la manutenzione non è più un’attività tecnica. È archeologia.
Martin, in The Clean Coder, insiste sul dire no. No a scadenze impossibili. No a compromessi che sai essere pericolosi. Non per rigidità, ma per professionalità. Perché ogni sì irresponsabile è un problema futuro garantito.
Naturalmente dire no è difficile quando c’è pressione. Quando c’è un cliente. Quando c’è una board. Ma non dirlo ha un costo sistemico. E quel costo, prima o poi, lo paga qualcuno. Spesso il team stesso, in forma di weekend bruciati e notti insonni.
La qualità è anche questo: proteggere il sistema da decisioni prese in stato di euforia o panico.
L’illusione moderna: produrre senza capire
C’è un aspetto contemporaneo che rende tutto questo ancora più interessante. O più inquietante.
Oggi possiamo produrre codice senza capirlo fino in fondo. Strumenti avanzati, generatori, suggerimenti automatici. Scriviamo più velocemente. In certi casi, scriviamo meglio. In molti altri, scriviamo senza aver attraversato davvero il problema.
Il rischio non è l’automazione in sé. Il rischio è la separazione tra scrittura e comprensione.
La manutenzione zen richiede presenza. Richiede sapere cosa stai toccando. Richiede una mappa mentale del sistema. Se la produzione di codice diventa un flusso semi-automatico, ma la comprensione resta limitata, stai solo aumentando il divario tra ciò che esiste e ciò che sai.
E quel divario si chiama debito cognitivo.
Puoi avere un sistema che compila, passa i test, scala. Ma se nessuno lo capisce davvero, la manutenzione diventa un atto di fede. E la fede, in produzione, è un pessimo piano di disaster recovery.
La qualità non è throughput. Non è numero di PR. Non è velocità di merge. È capacità di intervenire con lucidità quando qualcosa cambia. È resilienza cognitiva del team.
La manutenzione come atto di carattere
La cosa più potente che puoi estrarre dal libro di Pirsig, e incastrare senza forzature nel mondo del software, è questa: la qualità è una pratica che forma chi la esercita.
Manutenere bene non è solo una questione tecnica. È una postura mentale. È accettare che il tuo lavoro non finisce quando qualcosa “funziona”. È sapere che qualcuno, probabilmente tu stesso tra sei mesi, dovrà metterci mano.
Ogni riga che scrivi è un messaggio al futuro. Può essere un invito alla collaborazione o un campo minato.
Non esiste framework che garantisca qualità. Non esiste metodologia che sostituisca l’attenzione. Non esiste tool che renda professionale chi non vuole esserlo.
La manutenzione è l’attività meno celebrata e più determinante del nostro mestiere. Non finisce nelle slide, non fa marketing, non genera hype. Ma è ciò che distingue un sistema che dura da uno che implode.
E forse il punto di contatto più forte tra Lo Zen e l’arte della manutenzione della motocicletta e libri come Clean Code o The Pragmatic Programmer è proprio questo: il software non è solo qualcosa che funziona. È qualcosa di cui ti prendi cura.
Puoi scegliere di correre sempre. Di consegnare sempre. Di ottimizzare sempre.
Oppure puoi scegliere, ogni tanto, di fermarti e cambiare l’olio.
Non ti applaudiranno.
Ma la moto, domani, partirà.
