Sareste sorpresi di sapere che gli sviluppatori testano il loro software? Potrebbe non sembrare con tutte le interruzioni di quest'anno, ma lo sviluppatore medio dedica il 42% della sua settimana lavorativa alla manutenzione. Allora perché tutte le interruzioni?
Crowdstrike potrebbe aver fatto il tonfo più fragoroso, ma nel 2024 si sono verificate interruzioni che hanno bloccato le consegne dei fast food, messo offline WhatsApp e Instagram, bloccato i passeggeri all'aeroporto di Heathrow e bloccato il cibo alla frontiera della Brexit.
Queste interruzioni non sono avvenute perché gli sviluppatori non hanno testato il software. Sono avvenuti a causa di configurazioni software ipercomplesse: troppe modifiche ai prodotti da parte di troppe persone per troppi motivi. Molte aziende stanno testando il codice all'interno di un'architettura software che nessuno capisce più. È una torre di Jenga orribilmente grande. Un solo altro "blocco caratteristico" potrebbe far crollare l'intera struttura. Nessuno vuole toccarlo. Nessuno ricorda nemmeno come è stato costruito. Ma prima o poi un dirigente decreta: "Questo prodotto ha bisogno dell'intelligenza artificiale".
È l'eterna battaglia dell'ingegneria del software: innovazione contro manutenzione, che sta erodendo il tessuto stesso del software mondiale.
Perché il software si sta erodendo?
Come le rocce e le montagne, il nostro software si sta lentamente erodendo nel tempo. Se il software è una roccia, gli sviluppatori sono il vento e l'acqua che la disgregano.
Si aggiungono così tanti nuovi codici alle basi che influiscono, o vengono influenzati, da altre parti mobili del software, da far esplodere la complessità dei prodotti. In parte ciò è dovuto alle pressioni dei dirigenti per superare i concorrenti, ma a volte gli sviluppatori cercano semplicemente di ridurre i flussi di lavoro.
A uno sviluppatore viene chiesto di aggiungere una nuova funzionalità. Questa funzione gonfia la base di codice. Lo sviluppatore aggiunge una scorciatoia per lavorare più velocemente, che aggiunge complessità. Un manager chiede allo sviluppatore di espandere il prodotto. La scorciatoia di prima? È incompatibile con l'aggiornamento. Le cose si rompono. Lo sviluppatore inizia a correggere. Ci vuole molto tempo. Lo sviluppatore aggiunge un'altra scorciatoia e .... e così via.
L'erosione del software finisce per diventare una profezia che si autoavvera: una reazione a catena destabilizzante, in cui la più piccola patch per la qualità della vita diventa un grattacapo da implementare e un rischio per la funzionalità dei team.
Il costo umano dell'erosione del software
Se oltre il 40% del tempo di sviluppo serve solo a mantenere in vita il codice, questo non significa aggiungere valore al prodotto. Se si considerano anche le riunioni, il tempo per i commenti e il feedback, eccetera, sicuramente rimane meno della metà della settimana per lo sviluppo a valore aggiunto.
Questo è sconvolgente per un responsabile dello sviluppo, che improvvisamente può utilizzare solo metà del tempo per innovare. Per gli sviluppatori è ancora più penoso: che tipo di soddisfazione e di orgoglio possono trarre dall'aggiustare continuamente una linea di codice che continua a rompersi? L'eventuale disastro dell'outage e il conseguente errore di pubbliche relazioni sono solo un ulteriore colpo al morale.
Il passo successivo è il logorio degli ingegneri che ne hanno abbastanza. L'inserimento di nuovi ingegneri allunga i tempi di commercializzazione, frustrando tutti i soggetti coinvolti. I vecchi errori riaffiorano, altre persone se ne vanno, ma ora si tratta anche di veterani. Dove finisce?
Correggere le stesse cose
L'infelicità ciclica di molti sviluppatori non finirà finché non risolveremo il problema dello "shift left".
Risolvere il problema dello "shift left" non significa solo scaricare più tempo per i test sulle agende degli sviluppatori. Alcune aziende assumono tester QA esterni per ridurre l'onere, ma si tratta di una soluzione costosa. È come mettere del nastro adesivo sulle falle di un ponte.
Una soluzione tardiva è una soluzione costosa. Il rimedio meno costoso è quello di sistemare l'architettura quando la si sta ancora progettando. Inserite la QA nello sviluppo del software prima di scrivere tutto il codice, non dopo. Se siete all'inizio della fase di prototipazione, la QA potrebbe essere una spesa superflua. Ma nel momento in cui si costruisce un'attività redditizia che attrae clienti, è necessario un codice di qualità. Non volete perdere i clienti all'inizio del ciclo di vita del vostro prodotto. Se il vostro prodotto viene consegnato la prossima settimana e dovete riprogettare la vostra architettura per evitare un richiamo del prodotto, si tratta di una catastrofe di proporzioni epiche. Questo farà slittare i tempi di commercializzazione, farà lievitare i costi di sviluppo e farà esaurire tutti i collaboratori.
Come si ottiene codice di qualità? Servono più fonti di informazioni. Non lesinate sull'analisi statica del codice e sui test funzionali, che devono essere eseguiti ogni volta che si scrive nuovo codice. Dovete sapere quanto codice state clonando, dove si trovano le dipendenze nascoste, come i componenti comunicano tra loro, ecc. Quando si conoscono queste cose e si esegue la verifica dell'architettura, è più facile identificare i problemi. Se non potete eseguire subito ogni tipo di test, va bene, ma iniziate a costruire questi processi nel tempo.
Ma soprattutto, la vostra architettura vi permette di raggiungere i vostri obiettivi? Se non è così, è ora di riarchitettare. Un'azienda con decenni di codice legacy potrebbe non essere in grado di farlo, ma una PMI con cinque anni di codice? La litigiosità dei clienti insoddisfatti è superiore ai grattacapi che comporta impostare tutto nuovamente.
È importante anche capire che i diversi ruoli hanno incentivi diversi. Gli sviluppatori a volte si oppongono all'analisi statica del codice perché è un "lavoro aggiuntivo" e aggiunge tempo ai progetti. Di chi dovrebbe essere la responsabilità?
Con le interruzioni e i bug paralizzanti che iniziano a sembrare una moneta da pochi centesimi, non è mai stato così importante capire come è stata costruita la torre Jenga. Sono troppo poche le persone che conoscono a fondo la propria architettura. Con un po' di disciplina, questa situazione può cambiare. Deve cambiare, perché quella torre crollerà presto.
