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.
Come si crea un debito tecnico?
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.
Come si risolve un debito tecnico?
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.
One thought on “Il debito tecnico”