TAZIO MIRANDOLA Web Applications Developer

Debito Tecnico

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

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

il debito tecnico può portare a conseguenze costose, fino al fallimento del progetto.

tuttavia, nel contesto di lavoro reale, una carta dose di "debito tecnico" non è eludibile e fa parte del gioco, occorre in ogni caso mantenerlo monitorato e avere un piano per ripagarlo, cioè mantenerlo entro limiti di guardia.

Il DT non è solo legato alla qualità del codice e dei test, ma anche alla gestione del progetto, del team, delle specifiche e delle stime delle tempistiche.

Cunningham idividua gradi di gravità del debito:

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à 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.

Grade Two: lazy developers. meno tipicamente all’incapacità degli sviluppatori di gestire e far evolvere codice scritto da altri. è dovoto al fatto che modificare codice scritto da altri è più difficile che modificare il proprio codice perché molte informazioni sul motivo delle scelte operate e sul loro contesto non sono trasmesse.

Grade Three: pragmatic law. occorre riconoscere 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. Tuttavia, 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.

Grade Four: cannot move forward. Arrivati a questo punto, la complessità del sistema realizzato(DT) è, con molta probabilità, affetta da diversi problemi (bug) su cui bisogna intervenire. Gli stakeholder 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. paradossalmente, è il grado che si raggiunge più facilmente.

riassumendo: è sempre meglio ridurre il numero di features realizzate, ma gestire il livello di qualità stabilito, piuttosto che realizzare molte più features rinunciando però ad una costruzione solida e ben testata. il conto prima o poi si paga!