Un software si progetta con le migliori intenzioni ed architettura possibile, ma è quasi inevitabile che durante la sua storia produttiva accumuli un debito tecnico: vediamo di cosa si tratta e cosa fare.

Quando spiego l’argomento ad un team prendo come esempio l’Italia: una nazione intera che ha accumulato un debito tecnico enorme.

La burocrazia italiana è leggendaria? È un debito tecnico.

L’informatizzazione va lenta e sembra governata da un gregge di capre? È un debito tecnico.

Tornando al software, per quanto grosso sia il debito tecnico che abbiamo accumulato, la nostra situazione è rosea in confronto.

La spiegazione più comune è che, per fretta, si fanno modifiche al software non previste, incollate a scotch e queste, accumulandosi nel tempo, aumentano la complessità dei lavori successivi, rallentando tutto.

Questa spiegazione semplicistica, che tende a dare la colpa a “prodotto” che è cattivo e non dà il tempo di fare le cose per bene, non mi ha mai convinto del tutto.

Il debito tecnico può essere causato anche da altri fenomeni, quali:

• L’evoluzione del linguaggio di programmazione usato, rende parti del codice deprecate o obsolete.
• Librerie utilizzate massivamente sul codice smettono di essere supportate.
• Nuovi arrivati nel team di sviluppo, anche junior, vengono lasciati un po’ troppo liberi di intervenire nella codebase, senza conoscerne a pieno l’architettura.
• Il CTO non sorveglia abbastanza sull’andamento del software, dando precedenza a nuove features o altri accorgimenti.
• La pressione di clienti e prodotto causa sviluppi e correzioni con poca progettazione e riflessione.
• Il software si basa su una metodologia che si è poi rivelata migliorabile, come è giusto che sia, e l’architettura ne soffre.

La soluzione più logica sarebbe lavorare costantemente perché non si raggiunga mai. Questo purtroppo cozza con la vita reale di un team di sviluppo e di un’azienda di prodotto software.

I debiti tecnici (già spesso sono diversi) vanno considerati come bug urgenti che impattano sui clienti. Questo causerà malumori a prodotto e alle sue ottimistiche roadmap, ma ogni debito tecnico risolto è un risparmio di tempo enorme successivo.

L’alternativa, il lasciarlo andare, è molto peggiore. Si rischia di dover bloccare tutto lo sviluppo e fare un refactoring completo, con mesi di delirio e paura. Se torniamo all’esempio “Italia”, immaginate l’enormità del task.

Che debiti tecnici ha il vostro prodotto? Come li state affrontando? Non nascondeteli sotto il tappeto, mi raccomando.