Il concetto di Debito Tecnico (technical debt) è già emerso in diversi nostri post, in particolare in “ALM, un approccio pratico alla gestione del Debito Tecnico” dove abbiamo introdotto le iterazioni CBTi, ovvero le Clean Technical Debt Iteration, e la loro gestione tramite TFS.

Il concetto che si cela dietro le CBTi è esplicitamente evidenziato in SAFe nella HIP iteration, che ha tre obiettivi primari:

• Hardening
• Innovation
• Planning

Ma torniamo all’elemento centrale del post, riportando la definizione di “debito tecnico” presente su Wikipedia:

“[Technical Debt is] a neologistic metaphor referring to the eventual consequences of slapdash software architecture and hasty software development”

“[Il Debito Tecnico] è una metafora per indicare le eventuali conseguenze derivanti dalla frettolosa definizione di un’architettura software e da un altrettanto frettoloso sviluppo]

per completezza va ricordato che il termine “technical debt” è stato utilizzato per la prima volta da Ward Cunningham, parlando della complessità di far evolvere nel lungo periodo un sistema progettato tenendo conto solo dell’immediato (breve/brevissimo periodo)

Risulta ovvio che, se non trattato adeguatamente, il debito tecnico può portare a conseguenze molto forti, fino al fallimento del progetto stesso.

Nonostante ciò, bisogna, però, sempre vedere il bicchiere mezzo pieno! Infatti non esiste progetto che non abbia debito tecnico, e se pensiamo che il nostro progetto non ne sia affetto, probabilmente abbiamo una fiducia eccessiva in quel che stiamo realizzando e nelle nostre competenze, portandoci ad essere saccenti senza valutare correttamente il contesto (inspect-and-adapt) e generando, sicuramente, del lavoro con forti criticità o parzialmente inutile (waste).

Tale considerazione nasce dal fatto che il debito tecnico non è “banalmente” legato a codice scritto male o non testato ma dipende da fattori intrinsechi, legati al Team e al loro piano di azione.

Partendo dall’assunto che è possibile “gestire” un certo grado di debito tecnico, vediamo come classificare, spannometricamente, il debito stesso a seconda della gravità, dal grado più basso (e quindi più gestibile) a quello più alto e non più tollerabile:

• Grade one: framework changes and evolution. Oggi, praticamente, nessun software viene scritto da zero, preferendo sempre l’adozione di un framework che fornisce quante più funzionalità cross-domain possibili. Ma ogni framework evolve (i più utilizzati evolvono anche con estrema rapidità) e per quanto sia garantita una retro-compatibilità, escluse ovviamente le nuove funzionalità, prima o poi arriverà il cosiddetto “breakdown time” in cui non sarà più possibile garantirla. Va da sé che per ovviare a tale problema e sfruttare a pieno le nuove caratteristiche bisogna adattare una corretta strategia di aggiornamento e dedicare tempo e risorse ad essa. In questo contesto è forse superfluo sottolineare come pratiche di “continuous integration”, supportate da test automatizzati, consento di approcciare al problema in modo sistematico e abbattere il debito tecnico relativo; 
• Grade Two: lazy developers. Si tratta di una condizione particolare, dovuta spesso alla “pigrizia” (meno tipicamente all’incapacità) degli sviluppatori di gestire e far evolvere codice scritto da altri. Ogni sviluppatore è in grado (si spera!) di scrivere un sistema da zero, ma solo ottimi sviluppatori sono in grado di lavorare su quanto realizzato da altri. La pigrizia, però, non si evidenzia solo sulla propria attività, piuttosto diventa particolarmente evidente nel lavoro in Team quando è necessario “remare all’unisono” per raggiungere gli obiettivi e trasformarsi, idealmente, in un High Performance Team. Tale obiettivo è, infatti, difficile da raggiungere e richiede un impegno costante sotto la supervisione di un Coach esperto per evitare che le divergenze diventino ingestibili e la soluzione prodotta diventi debitoria;
• Grade Three: pragmatic law. Nello sviluppo del software bisogna è necessario essere sempre pragmatici, riconoscendo che non c’è mai abbastanza tempo per sviluppare la soluzione perfetta. Bisogna riuscire a gestire correttamente il bilanciamento tra qualità, di quanto sviluppato, e tempo a disposizione, evitando di realizzare qualcosa di inutile che dovrà poi essere re-implementato. Un fattore particolarmente ostico è riuscire a comprendere la complessità (Story Point, Ideal Days) di quanto ci si approccia a realizzare, cercando di effettuare una stima attendibile: nel caso in cui la stima sia troppo distante dalla realtà e il commitment non è rinegoziabile, si cade quasi sempre nella tentazione di produrre codice di bassa qualità per rispettare i tempi, aumentando esponenzialmente il debito tecnico. Se sia accetta, quindi, la condizione che esiste sempre un certo livello di debito tecnico, non essendo possibile raggiungere la soluzione ottimale poiché vincolata da fattori reali (es: tempo), possiamo definire tale debito tecnico come “debito tecnico nobile”. Quindi, tanto meno si riesce a creare il giusto bilanciamento tra risultato atteso e risorse disponibili, tanto più ci si avvicina rapidamente al quarto ed ultimo grado del technical debt;

Aumento esponenziale del Debito Tecnico

• Grade Four: cannot move forward. Arrivati a questo punto, il debito tecnico accumulato diventa evidente e non è più possibile ignorarlo perché il sistema realizzato è, con molta probabilità, affetta da diversi problemi (bug) su cui bisogna intervenire. Il catalizzatore? Gli stakeholder che notano ed evidenziano le lacune. Bisogna “pagare il debito accumulato” e fronteggiarne il costo (cost of servici the debt), esattamente come avviene con gli interessi della carta di credito, quando, per esempio, si va in rosso con il conto. La transizione tra il “terzo” ed il “quarto” grado può anche essere programmata, purché ci si appresti a pagare quanto prima il debito risultante. Si pensi, ad esempio, al nuovo software di contabilità per un’azienda che si trova a dover espletare alcuni obblighi normativi: se le funzionalità implementate sono sufficienti, allora si può decidere di rilasciare una prima release (deadline pressure) del software perché indispensabile. Si tenga conto che tale scelta è sempre rischiosa e il danno maggiore è spesso a carico del cliente, che accetta implicitamente una soluzione con funzionalità ridotte (ma non qualità ridotata!) rispetto a quella preventivata.

Deadline Pressure

Nonostante il quarto grado non dovrebbe mai essere raggiunto, paradossalmente, è quella che si raggiunge più facilmente. Questo perché non si è abituati ad un approccio Lean che consente di migliorarsi costantemente e, di conseguenza, migliorare il Team e quanto realizzato. Bisogna, ricordare, infine, che è sempre meglio ridurre il numero di features realizzate, garantendone sempre il livello di qualità stabilito in generale per la release che realizzare il doppio delle features rinunciando ad essa.

La qualità non è negoziabile, perché il conto prima o poi si paga!