Una situazione molto frequente per chi lavora nel mondo del software o IT in generale è assistere ad un rallentamento progressivo del ritmo a cui gli sviluppatori riescono ad evolvere un prodotto.
Il fenomeno sembra essere analogo ai quello dei pc windows che con il corso degli anni rallentano sempre maggiormente fino a diventare poco usabili.
In questo articolo voglio provare a dare una spiegazione prima intuitiva e poi più dettagliata del problema.
Lo scenario tipico è quello rappresentato dalla figura sottostante dove la freccia azzurra rappresenta la velocità dello sviluppo da una release a quella successiva:
Man mano che passa il tempo e si rilasciano delle release la valocità diminuisce fino a diventare difficilmente gestibile.
E’ il “classico caso” in cui il manager si stupisce del perchè una modifica “semplice” richieda un numero elevato di giornate.
Spesso alla velocità calante sono associati dei costi in aumento:
La situazione può degenerare fino al punto in cui si arriva alla conclusione che il prodotto deve essere rifatto.
Quale può essere una possibile spiegazione di un simile fenomeno?
Se le figure precedenti rappresentano un modello adeguato per descrivere la realtà ci deve essere qualcosa che rallenta lo sviluppo e che non è visibile (a chi dirige, i programmatori di solito intuiscono o sanno identificare il problema).
La figura sottostante completa il quadro:
Il gruppo di sviluppo porta con sè un peso sempre crescente che può diventare insostenibile.
E’ possibile dare un nome a questo fardello?
Sì: debito tecnico.
Ci sono varie definizioni di debito tecnico, la mia personale visione classifica come debito tecnico tutti quegli aspetti non funzionali (ovvero che non influiscono su cosa fa l’applicativo, ma su come è fatto l’applicativo) che sono spesso trascurati o poco gestiti.
Provo a fare alcuni esempi “intuitivi”:
- Mancanza di strutturazione del codice in layer applicativi
- Duplicazione nel codice di macro funzionalità
- Assenza di test unitari
Quali sono le cause di debito tecnico?
Ce ne sono svariate, quelle qui sotto sono quelle che ritengo più frequenti/importanti:
- La data di consegna troppo stringente
- La composizione del team di sviluppo troppo sbilanciata su figure junior
- La mancanza di conoscenza dello stack tecnologico utilizzato
E’ possibile evitare il debito tecnico?
Nella maggior parte dei casi no: ci sono scadenze che non possono essere differite per ragioni di arrivo sul mercato rispetto alla concorrenza, per scadenze legislative o simili o a volte anche perchè chi ha fatto un piano non accetta/non vuole comunicare di aver sbagliato e quindi insiste sulle proprie convinzioni.
E’ possibile gestire il debito tecnico?
Nella maggior parte dei casi sì, se si considerano i seguenti aspetti:
- E’ necessario avere coscienza che si sta creando un debito
- E’ necessario analizzare le principali cause del debito
- E’ necessario prevedere tempo e budget per sanare il debito
- E’ necessario usare il tempo e il budget previsto per sanare il debito
Il ciclo di gestione assomiglia di più alla figura sottostante:
Dove la velocità e i costi sono “normalizzati”.
Per chi volesse approfondire il tema consiglio questo articolo (in inglese), che offre degli spunti interessanti, oltre a riferimenti che cosentono di avere una visione più ampia.
La gestione del debito tecnico è molto più delicata nelle aziende “digitali” dove il tempo di rilascio è il fattore più importante, mentre per aziende “corporate” dove le economie di scala pesano di più la gestione è vincolata anche ad altri aspetti.
Programmatori dentro 