A volte quando si parla di "debito tecnico" nel mondo dello sviluppo software ci si riferisce (erroneamente) a una serie di incorrettezze nel codice accumulate dagli sviluppatori che possono compromettere i successivi sviluppi e il successo di un progetto. In realtà il significato del debito tecnico è più complesso di così, e comprenderlo aiuta a sviluppare strategie efficaci per gestirlo.
Ben Levy, sviluppatore software, sottolinea che il termine, ideato da Ward Cunningham, uno degli autori originali del manifesto Agile, identifica in realtà una metafora e viene usato per descrivere un intero fenomeno dello sviluppo software simile a un debito finanziario.
Come avviene nel mondo finanziario, in cui per ripagare un debito bisogna affrontare anche gli interessi, per recuperare un progetto sviluppato in maniera errata, con, per l'appunto, un debito tecnico significativo, serve uno sforzo che può aumentare in maniera considerevole nel tempo se non si agisce in tempi brevi.
Rimandare la gestione del debito non è la soluzione
La maggior parte dei debiti tecnici nasce da requisiti non presenti nella descrizione iniziale del sistema, i quali emergono in corso d'opera e spesso si discostano molto dal design di partenza.
Si tratta di un'eventualità quasi inevitabile e imprevedibile, ma il debito tecnico può aumentare o diminuire significativamente a seconda di come e quando viene affrontata. La soluzione più semplice e veloce sarebbe quella di ignorare la richiesta e proseguire con i requisiti iniziali, ma si tratta di una strada quasi mai percorribile.
Ciò che si fa più spesso è invece inserire il requisito "a forza" nel sistema, utilizzando soluzioni tutt'altro che ottimali, per non rallentare gli sviluppi; in questo caso il debito tecnico aumenta e, prima o poi, tornerà a chiedere gli interessi quando sarà troppo complesso ripagarli.
Il debito tecnico è spesso legato a una mentalità per la quale è più importante scrivere codice e consegnare un prodotto funzionante, anche se di qualità scadente, invece di prendersi del tempo per risolvere i bug e gestire adeguatamente i nuovi requisiti.
Le aziende, e di conseguenza i singoli sviluppatori, ragionano sul fatto che ci sarà tempo in futuro per sistemare il codice; tempo che, chiaramente, non verrà mai utilizzato per occuparsi di vecchi debiti.
Ciò che si dovrebbe fare è invece adattare il sistema per fare in modo che sia come se il requisito fosse sempre stato noto, cioè, rientrando nella metafora finanziaria, ripagando il debito quando è ora, senza rimandare. L'indicazione è quindi di ridurre al minimo le discrepanze non appena si presentano.
È necessario un cambio di mentalità
In alcuni casi i team di sviluppo vedono negli sprint di refactoring un modo per rivedere la code-base, riordinarla ed eliminare le logiche più complesse che complicano la manutenzione del software.
Sebbene prevedere delle sessioni di refactoring può essere utile a individuare problematiche non note e risolvere alcuni bug, la mentalità alla base, secondo la quale il refactoring è la panacea di tutti i mali, è sbagliata: il problema non sta esclusivamente nel codice in sé, il quale può comunque essere migliorato, ma nei processi che hanno portato a quella situazione.
Se l'intera azienda non cambia modo di pensare, il debito tecnico diventa un problema di qualsiasi processo, non solo degli sviluppi del singolo progetto. Per Levy andrebbe ripensato interamente il modo in cui si struttura il lavoro: ogni volta che c'è una nuova richiesta di funzionalità bisogna rivedere il design del sistema e adattarlo come se l'avesse sempre prevista, e solo dopo cominciare con gli sviluppi.
Ignorando questo problema si può arrivare a uno scenario in cui il codice diventa subito "legacy" perché è impossibile manutenerlo senza riscriverlo completamente. Lo sviluppo software non deve essere reattivo, ma deve diventare un processo olistico e proattivo.
Il concetto di debito tecnico va approfondito in ogni sua manifestazione, riconoscendo che, in una certa quantità, è del tutto normale che sia presente ed è ancora gestibile. Il problema è l'accumulo del debito che, se trascurato, può portare a uno stato ingestibile che causa frustrazione negli sviluppatori e possibili abbandoni; per questo è necessario agire in modo equilibrato e proattivo, cercando di non lasciare alcuna questione irrisolta.