In questo primo articolo del blog non parlo di un problema nuovo, né di qualcosa che, purtroppo, gli sviluppatori possono evitare. Il debito tecnico, ed è stato al centro di molte ricerche e articoli dell'incredibile Martin Fowler, tuttavia sfortunatamente, non è sempre visibile e identificabile nei vari progetti.

Per un programmatore alle prime armi diventa inizialmente pressoché impossibile identificarlo. Le sue risorse saranno occupate a imparare o approfondire la conoscenza di un linguaggio di programmazione e di un software su cui magari non c'è molta documentazione.

Quindi, cos'è il debito tecnico?

Wikipedia ci dice:

“Il debito tecnico è una metafora inventata da Ward Cunningham per descrivere le possibili complicazioni che subentrano in un progetto, tipicamente di sviluppo software, qualora non venissero adottate adeguate azioni volte a mantenerne bassa la complessità. Analogamente a quanto avviene nel mondo finanziario, in cui per sanare un debito occorre pagarne anche gli interessi. Lo sforzo per recuperare un progetto sviluppato senza una corretta metodologia può aumentare anche considerevolmente nel tempo, se non si interviene tempestivamente.

Questa è una definizione limitante. Implica in modo utopico che se durante la creazione e sviluppo del software, il creatore o il team non ha scelto la soluzione "facile" e ha avuto un tempo illimitato per consegnare il prodotto finale, non ci sarebbe stato debito.

Nella realtà partire da zero debiti è impossibile. La progettazione del software consiste in una serie di compromessi. Gli ingegneri "senior" del software sono bravi a scegliere il giusto compromesso, hanno dalla loro parte anni di esperienza e una forte comprensione di ciò che li aspetta che spesso viene chiama "lungimiranza".

Ma con compromessi arriva "il compromesso": quindi abbiamo sempre qualche debito tecnico in tutti i sistemi che costruiamo.

Come suggerisce il nome, il debito tecnico è come il debito finanziario. Devi prendere in prestito dal futuro per effettuare consegne oggi. Non possiamo continuare ad aspettare e pensare troppo a scenari futuri, altrimenti perderemo le opportunità di oggi.

È giusto dire che il software dovrebbe aiutare a raggiungere un risultato aziendale collettivo oggi e domani... ma potrebbe non esserci un domani se il software non viene consegnato oggi.

Come il debito finanziario, il debito tecnico non è brutto

E' necessario, non possiamo evitarlo. Nel tempo, accumulerà interesse. Questo interesse rende più difficile per gli sviluppatori creare funzionalità e per l'azienda trarne un valore.

Cosa può fare uno sviluppatore individuale per contribuire a ripagare questo debito?

Come primo suggerimento si deve comprendere bene la propria organizzazione aziendale: la gestione del debito tecnico è un problema che deve essere risolto a livello organizzativo, di team di prodotto, team di sviluppo e in ultimo ma non meno importante a livello individuale.

In questo articolo farò alcune supposizioni, perché questo fa parte della mia esperienza:

  1. Si fa parte di un team di sviluppo agile.
  2. Il tuo team agile è per la maggior parte auto-gestito.
  3. Hai l'esigenza di fornire stime dei lavori necessari per completare le funzioni assegnate a te.

Ama il tuo debito

Amare, in certe circostanze, rappresenta uno scambio, una condivisione, una conoscenza e un rispetto reciproco fra due persone.

Nel mondo dello sviluppo del software amare il proprio prodotto specialmente se sei in un team è fondamentale, richiede un vero impegno (come ogni relazione) e richiede uno studio approfondito, che sfocia in una conoscenza e rispetto reciproco, perchè se si conosce quello che si sta facendo si riceverà sempre qualcosa di buono e utile.

Si deve evitare di sviluppare cose che non puoi gestire, perchè se non si è stati attenti nella valutazione, il software in cambio genererà sempre problemi e il debito aumenterà.

Domina il debito tecnico

Uno dei migliori approcci che si possono attuare è proporre in alcuni casi dei refactoring specialmente piccoli ma strategici. Sicuramente non tutti i compagni del team potranno essere d'accordo.

Se il problema o debito è di entità importante, far fare una valutazione sul tempo impiegato nel rilascio delle fixes rispetto a "perdere" un pò di tempo extra nel rilascio di una funzionalità rivista e migliorata è molto meglio e farà guadagnare del tempo in futuro (è analogo ad un concetto di buon investimento).

A volte è possibile che la proposta possa venire scartata durante una riunione del team, ma questo può portare a due tipi di valutazione:

  • Raccogliere più informazioni e migliorare la proposta di modifica
  • Sottolineare l'impatto che potrebbe avere sugli utilizzatori del software
  • Descrivere uno scenario di fix multipli e un rilascio unico che prevede una revisione e una possibile attenuazione o del debito

Conclusioni

Il debito tecnico quindi è un concetto con cui tutti gli sviluppatori debbono convivere. Tuttavia sia nella fase progettuale che nella fase poi di mantenimento questo debito può cambiare e non peggiorare.

Il debito tecnico può anche attenuarsi e diventare invece una parte dell'investimento.

Come scelta personale ho deciso di puntare molto sul concetto di investimento, investimento che comporta anche delle personalizzazioni che rappresentano compromessi per un investimento che sia io che i miei clienti debbono affrontare.