Il costo nascosto della manutenzione evolutiva

Ogni lunedì mattina, in qualche ufficio del mondo, un amministratore di database lancia la stessa query correttiva. Non si tratta di un’attività pianificata o documentata, ma di un rituale necessario per riparare i danni che il sistema accumula puntualmente ogni weekend. Quando gli viene chiesto perché non si risolva definitivamente il problema, la risposta è sempre la stessa: “Abbiamo provato”.

Questa scena si ripete in migliaia di organizzazioni con una regolarità quasi comica. La manutenzione evolutiva del software non è un problema tecnico, è un problema culturale che nessuno vuole affrontare fino a quando l’intera infrastruttura non minaccia di crollare.

Il mito della tecnologia stabile

Le aziende investono mesi nella scelta della tecnologia perfetta. Comitati si riuniscono, consulenti vengono pagati cifre astronomiche, documenti di valutazione crescono fino a dimensioni enciclopediche. Alla fine, viene selezionato il framework ideale, quello che promette stabilità, supporto pluriennale e una community robusta.

Il giorno successivo al primo deploy, quella promessa di stabilità inizia a sgretolarsi. La versione utilizzata nel progetto è già superata da tre aggiornamenti minori. Entro un mese, una nuova major version viene annunciata con funzionalità rivoluzionarie che rendono obsoleto l’approccio appena implementato.

La verità scomoda è che la stabilità è un’illusione di marketing. Esistono solo gradi diversi di instabilità e velocità variabili di cambiamento. Anche le tecnologie considerate mature e affidabili attraversano cicli di evoluzione che possono rendere complessa qualsiasi strategia di lungo termine.

Quando rimandare diventa una strategia

Il paradosso della manutenzione software è che più viene rimandata, più diventa costosa e rischiosa. Eppure, questa è esattamente la strategia adottata dalla maggioranza delle organizzazioni. Non per incompetenza o negligenza, ma per una ragione molto più pragmatica: le scadenze immediate vincono sempre sulle necessità future.

Immaginate un’applicazione che gira su versioni di framework vecchie di cinque anni. Funziona perfettamente, i clienti sono soddisfatti, nessuno si lamenta. Proporre un aggiornamento significa bloccare lo sviluppo di nuove funzionalità per settimane, rischiare regressioni, investire in test approfonditi. Il management guarda i numeri e decide che il rischio non vale la candela.

Passa un anno, poi due, poi cinque. I developer originali hanno cambiato azienda, portando con sé la conoscenza implicita del sistema. La documentazione tecnica, se mai è esistita, è ormai inaffidabile. Le dipendenze si sono moltiplicate in una ragnatela di interconnessioni che nessuno osa più toccare.

Quando finalmente arriva il momento di aggiornare, magari forzato da una vulnerabilità di sicurezza critica, la situazione è degenerata. Passare dalla versione 3.2 alla 11.5 non è più un aggiornamento, è un’archeologia informatica. Ogni major version intermedia ha introdotto breaking changes che si sommano in una cascata di incompatibilità.

L’illusione dell’aggiornamento continuo

All’estremo opposto si posizionano le organizzazioni che hanno abbracciato la filosofia dell’aggiornamento continuo. Ogni dipendenza viene aggiornata appena disponibile una nuova versione. I sistemi di continuous integration girano costantemente, i deployment sono frequentissimi, la parola d’ordine è “sempre all’ultima versione”.

Sulla carta, questa strategia dovrebbe eliminare il debito tecnico. Nella pratica, crea un’infrastruttura perpetuamente instabile. I team vivono in uno stato di allerta permanente, pronti a rispondere alle emergenze causate da aggiornamenti problematici. Le serate e i weekend vengono regolarmente sacrificati per risolvere incompatibilità impreviste o regressioni introdotte da patch apparentemente innocue.

Il costo nascosto di questa strategia è il tempo. Tempo sottratto allo sviluppo di funzionalità reali, tempo speso a inseguire l’ultima versione senza mai fermarsi a chiedersi se quella versione sia effettivamente necessaria o vantaggiosa. È come correre su un tapis roulant che accelera continuamente: si fa molta fatica ma non si arriva da nessuna parte.

La disciplina che nessuno ha

Esiste teoricamente una terza via: la manutenzione programmata e strategica. Categorizzare le dipendenze, aggiornare selettivamente quelle critiche, monitorare costantemente le vulnerabilità, dedicare risorse regolari alla pulizia del debito tecnico.

I team iniziano con entusiasmo. Vengono create dashboard elaborate per tracciare le versioni, impostati alert automatici, pianificati “giorni della manutenzione” ricorrenti nel calendario. I primi due mesi funzionano magnificamente. Poi arriva una deadline importante, un cliente strategico richiede una modifica urgente, il product manager promette una funzionalità senza consultare il team tecnico.

La manutenzione programmata salta una volta, poi due, poi semplicemente scompare dall’agenda. Le dashboard si riempiono di segnalazioni rosse ignorate, gli alert vengono silenziati perché troppo frequenti, il debito tecnico cresce silenziosamente come muffa in un angolo umido.

Il problema fondamentale è che la manutenzione è invisibile al business. Nessun cliente chiederà mai “avete aggiornato le dipendenze questo mese?”, nessun stakeholder misurerà il successo in base alla freschezza delle librerie utilizzate. La pressione è sempre e solo verso nuove funzionalità, più velocemente, con meno risorse.

I bug immortali e le loro conseguenze

In questo ambiente prolifera una specie particolare di problema: il bug diventato parte del sistema. Segnalato anni fa, riassegnato a decine di developer, migrato attraverso tre piattaforme diverse di issue tracking. La sua storia è più lunga e articolata della maggior parte dei progetti aziendali.

Nessuno lo risolve perché risolverlo richiederebbe modifiche profonde in componenti critici. Meglio convivere con le sue conseguenze, implementare workaround, aggiustare manualmente i dati quando necessario. Dopo tutto, se il sistema ha funzionato così per cinque anni, può continuare ancora un po’.

Questo approccio genera quello che potremmo chiamare “manutenzione correttiva perpetua”. Query manuali eseguite ogni mattina, script di aggiustamento lanciati prima dei backup, procedure non documentate tramandate oralmente tra colleghi. Un livello intero di complessità operativa che esiste solo per compensare problemi che nessuno ha il tempo o il coraggio di affrontare alla radice.

Il prezzo reale dell’inerzia

Quando finalmente l’obsolescenza diventa insostenibile, le opzioni sono tutte dolorose. Un refactoring massiccio che blocca lo sviluppo per mesi. Una migrazione graduale che richiede di mantenere due sistemi in parallelo. O, sempre più frequentemente, la decisione di riscrivere tutto da zero, sprecando anni di investimenti e conoscenza accumulata.

Il costo finanziario di queste operazioni è enorme, ma impallidisce di fronte al costo umano. Team che bruciano settimane su problemi che avrebbero potuto essere evitati, developer senior che se ne vanno frustrati dalla mancanza di tempo per fare le cose correttamente, conoscenza critica che evapora quando le persone cambiano ruolo.

La manutenzione evolutiva non è un problema tecnico risolvibile con strumenti migliori o processi più sofisticati. È un problema di priorità organizzative, di cultura aziendale, di capacità di bilanciare le necessità immediate con la sostenibilità a lungo termine.

Una questione di sopravvivenza

Ogni sistema software accumula entropia. È una legge fisica dell’universo digitale. La domanda non è se gestire questa entropia, ma quando e come. Rimandare costa meno oggi ma molto di più domani. Aggiornare troppo frequentemente crea instabilità. Pianificare strategicamente richiede una disciplina che pochi possiedono.

Non esistono soluzioni perfette, solo compromessi più o meno gestibili. Ma ignorare completamente il problema, sperando che si risolva da solo o che qualcun altro se ne occupi in futuro, è la garanzia matematica di un disastro annunciato.

Il codice scritto oggi diventerà legacy domani. Le decisioni prese ora determineranno quanto sarà dolorosa la manutenzione tra cinque anni. E quando quel futuro arriverà, i responsabili di quelle decisioni saranno probabilmente altrove, lasciando ad altri l’onere di gestire le conseguenze.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• BACK OFFICE MANAGER
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• SOC MANAGER 
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT