Che sia per gli sviluppatori o la direzione di un’impresa, il debito tecnico è una questione di primaria importanza. Un codice obsoleto e un’implementazione mal consolidata possono creare molta complessità, costi elevati e problemi che devono essere compensati tramite sforzi supplementari. In qualità di provider cloud riconosciuto in tutta Europa, ci troviamo ovviamente di fronte a questa sfida continua. In questo articolo, condividiamo la nostra esperienza su questo problema attraverso uno dei prodotti di punta della nostra suite di strumenti di produttività online, l’interfaccia web che consente di gestire la messaggistica online.

Il debito tecnico è spesso escluso dalle priorità perché non genera un valore immediato per l’impresa, ma può rapidamente diventare un peso morto che impedisce qualsiasi progresso futuro. Julien Arnoux, VP of Engineering

Il debito tecnico: una bomba a orologeria che può avere un impatto critico sul business 

Offrire funzionalità soddisfa il mercato. Spesso si accelera, anche a costo di ignorare le vecchie parti del codice di cui “ci occuperemo più tardi”. Ma quando gli obiettivi aziendali nascondono la qualità del codice sotto il tappeto, ecco cosa accade:

Per gli sviluppatori: è la frustrazione

Ogni iterazione aumenta il debito. Eppure continuiamo a evolvere su basi software create X anni fa e che non corrispondono necessariamente più a quanto serve oggi. Non si possono utilizzare i linguaggi più recenti, le macchine di preproduzione non sono uguali a quelle di produzione… Ci infliggiamo pratiche obsolete con blocchi che si moltiplicano e anche il rischio di errori. Così non tocchiamo più niente per paura di rompere tutto. La montagna di compiti ingegneristici cresce, lo stress si ripercuote sui team che perdono ingegneri a causa del duro lavoro.  

Da parte dei manager: è l’incomprensione

Di solito risolviamo i problemi con le “quick fix”, ma adesso ci vogliono due settimane solo per cambiare i pulsanti nell’interfaccia. Per cercare di rispettare scadenze irrealistiche, si mettono sotto pressione gli sviluppatori che “mancano di rigore” quando costantemente chiamati a combattere problemi tecnici e bug. La produttività diminuisce e la motivazione fatica a resistere.

Per la direzione: niente va abbastanza veloce

Sono in gioco il denaro e la redditività. Perché ci vuole così tanto tempo per fornire valore? Perché il sito è lento? Perché modernizzare il codice se questo non risolve nessuno dei problemi espressi dai clienti? Ad esempio, i responsabili delle decisioni possono essere tentati di compensare i rallentamenti con una soluzione immediata, come l’aggiunta di potenza server, anche se ciò non risolve il debito tecnico sottostante che continuerà ad avere un impatto sempre maggiore sulla qualità del codice nel lungo periodo.

Le cifre parlano da sole: nelle aziende, il debito tecnico sarebbe responsabile dal +10% al 20% dei costi di ogni progetto, fino a 13,5 ore settimanali di risoluzione dei problemi per collaboratore e circa il 30% del budget informatico annuale.

Se non riusciamo a trovare l’equilibrio, andremo dritti contro il muro. I rischi sono evidenti:

  • Perdita di velocità
  • Problemi di sicurezza
  • Demotivazione dei team (tecnica e prodotto)
  • Pacchetti software di scarsa qualità

Ma di cosa stiamo parlando esattamente con il debito tecnico?

Il debito tecnico è la differenza tra il codice attuale e quello che dovrebbe essere idealmente. Quindi, minore è la qualità del software, maggiore è il debito.

È inevitabile, che sia intenzionale o meno 

Si può sacrificare la qualità del codice per trarne un beneficio, se si ha un time to market molto breve o se un ritardo nell’uscita di una nuova versione è finanziariamente insostenibile, ad esempio. In questo caso, l’indebitamento è intenzionale, ma nella maggior parte dei casi non lo è, perché il debito tecnico è inerente al nostro mestiere.

Aumenta con ogni riga di codice 

Più si procede con le iterazioni, più si aumenta la complessità del software e il disordine.

Il primo problema è la complessità essenziale del nostro mestiere. Per il Servizio Mail, ciò significa poter interagire con un server di posta in modo rapido ed efficace e mettere a disposizione un’API che può essere utilizzata da una webapp e applicazioni mobili.

Poi arriva la complessità accidentale con i problemi dovuti alla cattiva qualità del codice. Dipende anche dalle scelte tecniche che si fanno, ad esempio:  durante il rifacimento della precedente versione del Servizio Mail, una parte del codicebase è stata recuperata dalla primissima versione scritta oltre 15 anni fa. Questa usava un altro sistema di archiviazione per le e-mail. Abbiamo quindi ereditato tutta una serie di complicazioni inutili anche se non abbiamo utilizzato questo sistema per molto tempo.

E infine il disordine naturale (entropia software). Si inizia con una semplice base software a cui si aggiungono i moduli man mano che un’applicazione si sviluppa. La logica finisce per aggrovigliarsi e diventa difficile da capire soprattutto se uno sviluppatore lascia il team. Ci ritroviamo con pezzi di codice che non servono più a niente, ma che aumentano la complessità:

Cosa succede quando il debito tecnico si accumula

Si finisce per passare più tempo a compensare le difficoltà piuttosto che a creare funzionalità e ad aggiungere veramente valore al software:

Allora, come affrontare il debito tecnico?

È una questione di equilibrio, il compromesso tra qualità e costi, è quasi il dato di base nello sviluppo del software.

Iniziare per renderlo visibile

È importante convincere tutti: i colleghi, i manager, i dirigenti. Non è facile? È essenziale tradurre il debito tecnico per i manager e i CEO spiegando i seguenti punti:

  • mostrare che i vantaggi a breve termine compromettono la competitività a lungo termine;
  • spiegare che i problemi tecnici si trasformeranno in una perdita di clienti;
  • sensibilizzare al fatto che il codice obsoleto riduce la prevedibilità e rende opaco il progetto.

“Modernizzare il proprio codice non è uno snobismo da sviluppatori”. È una necessità per il business:

I team che riducono il proprio debito tecnico liberano fino al 50% di tempo in più per creare valore.

Fermare l’emorragia per evitare l’accumulo in corso

Non cambieremo la cultura di un team dall’oggi al domani, ma dobbiamo essere consapevoli dei fattori aggravanti per limitarli al massimo:

  • scadenze non sostenibili
  • definizione errata del bisogno
  • cattiva organizzazione dell’impresa (compartimentazione dei team)
  • mancanza di conoscenza professionale
  • sul piano tecnico: cattive pratiche, assenza di documentazione, over-engineering, assenza di test, ecc. 

3 principi che possono anche aggravare il debito:

  • Nessuna soluzione miracolosa. I framework che promettono di risolvere tutti i problemi non esistono.
  • Evitare il mimetismo: “Netflix fa microservizi”, “Google è in monorepo”. Fare la stessa cosa degli altri “perché lo fanno” non produrrà i risultati attesi in un contesto diverso (vedere Culto del cargo). 
  • La sindrome della finestra rotta: è l’idea che lasciando una finestra rotta in un edificio senza ripararla, questo causerà l’inciviltà e il deterioramento di altre finestre dell’edificio, poi dei muri, poi del quartiere, e così via. Questo è molto comune nel software: si ha meno esitazione a inserire un pezzo di codice scadente se lo stato generale del codice è già pessimo e ci si ritrova con una montagna di codice spaghetti da mantenere.

Alcuni principi da applicare per evitarlo:

  • La regola del boy scout: lascia l’area dove ti sei fermato più pulita di come l’hai trovata. Grazie per i prossimi;-) 
  • K.I.S.S. : Keep it simple stupid (rendere le cose semplici è complicato, ma fallo comunque).
  • Y.A.G.N.I. : You ain’t gonna need it (noi sviluppatori siamo molto bravi ad aggiungere cose “caso mai” ne avessimo bisogno…) 
  • D.R.Y. : Don’t repeat yourself (invece di duplicare il codice, si cerca in tutti i modi di fattorizzarlo in un altro modo).

In generale, le tecniche artigianali sono una buona risorsa.

Come ripagare il debito tecnico esistente?

E qui, si entra nel vivo della questione. Se vogliamo avere il massimo impatto: 

  1. Individuare le aree a rischio per il debito tecnico.
  2. Illustrare i benefici e trattarli
  3. Categorizzare: sicurezza, manutenibilità, automazione, garanzia di qualità, integrazione continua…
  4. Definire la priorità dei debiti tecnici da ripagare in base al loro impatto
  5. Trattare

Ad esempio:

  • “Ho una dipendenza che è superata da 6 mesi. Non è più mantenuta e potenzialmente vi sono delle lacune in materia di sicurezza”.
  • Il beneficio: “evitare potenziali falle di sicurezza”.
  • Questo punto viene poi trattato in funzione degli altri debiti individuati a seconda delle priorità e dell’impatto perseguito. 

Investire regolarmente per ridurre il debito esistente 

Grazie al lavoro di identificazione è possibile pianificare il rimborso del debito tecnico e integrarlo nella roadmap del prodotto/servizio. Questa procedura va quindi effettuata con il Product Owner o il Product Manager.

Ripagare tutto? È una questione di misura.

Il debito tecnico è una corsa a lunga distanza. La ricerca della purezza del codice a tutti i costi è del tutto sterile, ma privilegiare la qualità contribuisce in larga misura al potenziale di sviluppo. Non avere software indebitato attrae gli sviluppatori piuttosto che farli fuggire. La cosa migliore da fare è rivalutare regolarmente il debito per regolare i cursori e seguire sempre la giusta rotta.

Scopri altro

Il webinar completo sul debito tecnico:

La conferenza illustra cos’è il debito tecnico, le sue origini, i rischi che esso comporta e come prevenirlo e ripagarlo. Julien Arnoux è VP of Engineering presso Infomaniak. Naviga nella tecnologia da oltre 15 anni; prima come sviluppatore, poi lead dev e infine VP. Ha potuto osservare i diversi aspetti dello sviluppo dei prodotti web, dalla tecnica all’organizzazione.