Debito tecnico: possibili con­se­guen­ze di uno sviluppo software economico

Un team di svi­lup­pa­to­ri che lavora in modo rapido ed economico sullo sviluppo di un software o l’in­stal­la­zio­ne di un’in­fra­strut­tu­ra in­for­ma­ti­ca ottiene questo risparmio tramite l’as­sun­zio­ne di un debito tecnico. Debito tecnico è il termine usato per designare le con­se­guen­ze di ne­gli­gen­za in­ten­zio­na­le o non in­ten­zio­na­le, errori e carenze nel codice, poiché cor­re­zio­ni e ma­nu­ten­zio­ni ral­len­ta­no la pro­dut­ti­vi­tà e com­por­ta­no costosi lavori ag­giun­ti­vi. A cosa occorre prestare at­ten­zio­ne se si vuole evitare un debito tecnico nello sviluppo del software?

Nel 1992, Ward Cun­nin­gham, pro­gram­ma­to­re e coautore del Manifesto per lo sviluppo agile di software, in­tro­dus­se la metafora del debito tecnico. Con questa immagine Cun­nin­gham ha voluto chiarire quanto sia im­por­tan­te per il software il re­fac­to­ring, ovvero la cor­re­zio­ne regolare del codice. Questo è l’unico modo per evitare che il software diventi sempre più in­de­bi­ta­to a causa di crescenti carenze fun­zio­na­li e debolezze strut­tu­ra­li.

Il termine debito implica anche un interesse, di con­se­guen­za il debito tecnico è per le aziende un’im­por­tan­te com­po­nen­te da con­si­de­ra­re dal punto di vista fi­nan­zia­rio. Il debito tecnico non solo comporta maggiori sforzi e riduce la pro­dut­ti­vi­tà a causa della con­se­guen­te ma­nu­ten­zio­ne, ma genera anche maggiori costi. Più un team leader trascura la ma­nu­ten­zio­ne di un’in­fra­strut­tu­ra o di un’ap­pli­ca­zio­ne IT difettosa, maggiore è l’interesse che il debito genera e più costose sono le cor­re­zio­ni del codice.

Secondo Ward Cun­nin­gham il debito tecnico deriva dalla ne­gli­gen­za nella pro­gram­ma­zio­ne del codice, che, a causa di vincoli di tempo o di budget, porta a una ri­so­lu­zio­ne dei problemi più rapida, ma errata. Un codice accurato e completo è complesso e lungo. Di con­se­guen­za, gli svi­lup­pa­to­ri possono scegliere di uti­liz­za­re un codice sporco, per ri­spar­mia­re tempo e fatica. Questi risparmi sono però ottenuti at­tra­ver­so il debito.

Per Cun­nin­gham questo aspetto economico della pro­gram­ma­zio­ne non è insolito o in­na­tu­ra­le. Ma se il debito tecnico non viene com­pen­sa­to dal re­fac­to­ring e il codice non viene re­go­lar­men­te ot­ti­miz­za­to, lo sviluppo si in­ter­rom­pe o si ferma a causa dei tassi di interesse.

Martin Fowler, autore di “Re­fac­to­ring: Improving the Design of Existing Code”, ha con­cre­tiz­za­to la metafora di Cun­nin­gham e ha suddiviso il debito tecnico in quattro tipi, il­lu­stra­ti nel quadrante del debito tecnico qui riportato:

Il debito tecnico secondo Cun­nin­gham e Fowler può quindi sorgere sia con­sa­pe­vol­men­te che inav­ver­ti­ta­men­te. Poiché la tec­no­lo­gia e la pro­gram­ma­zio­ne sono soggette a continue revisioni e mi­glio­ra­men­ti, è difficile evitare il code smell e il code erosion. Inoltre, il software invecchia e, in mancanza di ag­gior­na­men­ti e re­fac­to­ring, accumula debito. Nella maggior parte dei casi il debito tecnico può essere spiegato con scelte eco­no­mi­che o errori di pro­gram­ma­zio­ne in­ten­zio­na­li o non in­ten­zio­na­li.

Il debito tecnico di solito ha effetti simili sullo sviluppo del software, ma le sue cause possono variare no­te­vol­men­te.

• Mancanza di gestione della qualità: i progetti vengono eseguiti senza mec­ca­ni­smi di controllo, mi­su­ra­zio­ne e test di garanzia della qualità e ac­cu­mu­la­no debiti di continuo.
   
• Pressione economica: i fattori economici e lo sviluppo rapido del software sono prio­ri­tiz­za­ti su richiesta dei clienti o a causa della com­pe­ti­ti­vi­tà, e viene tra­scu­ra­to un codice pulito.
   
• Mancanza di qua­li­fi­che: le co­no­scen­ze tecniche del team di sviluppo non sod­di­sfa­no i requisiti di un codice elegante e pulito. Il risultato è un code smell o uno spaghetti code.
   
• Do­cu­men­ta­zio­ne / co­mu­ni­ca­zio­ne in­suf­fi­cien­te: il processo di sviluppo viene eseguito senza do­cu­men­ta­zio­ne parallela delle esten­sio­ni e delle modifiche del codice. Inoltre, le modifiche al codice non vengono re­gi­stra­te e co­mu­ni­ca­te ai pro­gram­ma­to­ri suc­ces­si­vi. Le pos­si­bi­li­tà di re­fac­to­ring sono limitate o non di­spo­ni­bi­li.
   
• Re­fac­to­ring differito: il debito tecnico de­li­be­ra­ta­men­te accettato non viene pron­ta­men­te risolto perché il re­fac­to­ring viene tra­scu­ra­to o rinviato.
   
• Sviluppo di ap­pli­ca­zio­ni parallele: fasi di sviluppo parallele riunite e non coor­di­na­te portano all’accumulo di debito.
   
• Codice troppo complesso: le sezioni del codice sono troppo com­pli­ca­te e illogiche. Piccoli cam­bia­men­ti possono portare a ulteriori errori e aumentare il debito. Nel peggiore dei casi anche qui viene generato lo spaghetti code.
   
• Processi di sviluppo non strut­tu­ra­ti: lo sviluppo dell’ap­pli­ca­zio­ne inizia prima che un progetto o dei processi specifici siano stati definiti e decisi.
   
• Codice di ou­tsour­cing: le fasi di sviluppo sono ester­na­liz­za­te e com­por­ta­no errori nel codice quando le sezioni vengono suc­ces­si­va­men­te unite; errori che la direzione del team accetta o trascura.
   
• Cam­bia­men­ti a breve termine nel processo: i cam­bia­men­ti a breve termine nel codice non vengono testati a causa dei tempi ristretti.

Ward Cun­nin­gham non solo ha definito la metafora del debito tecnico ma è anche coautore e primo fir­ma­ta­rio del Manifesto per lo sviluppo agile di software. Questa filosofia nello sviluppo del software mira a pro­muo­ve­re lo sviluppo e la pub­bli­ca­zio­ne di ap­pli­ca­zio­ni più pro­dut­ti­ve e fles­si­bi­li.

Invece di essere legati a progetti di grandi di­men­sio­ni per lunghi periodi di tempo, i team diventano più piccoli e in­di­pen­den­ti e do­vreb­be­ro mirare a ottenere fasi di lavoro più brevi e release più rapide per progetti minori quali ap­pli­ca­zio­ni, parti di programma e ag­gior­na­men­ti.

Lo sviluppo agile del software comporta che i team possano scrivere e mo­di­fi­ca­re il codice in piccoli passaggi rendendo quindi possibile che le fasi di lavoro vengano com­ple­ta­te più ra­pi­da­men­te. Infatti, con­cen­trar­si su velocità e pro­dut­ti­vi­tà aumenta il rischio di ac­cu­mu­la­re un codice sporco e quindi un debito tecnico. So­prat­tut­to quando lo sviluppo agile del software è eseguito senza un cor­ri­spon­den­te re­fac­to­ring continuo, il debito ine­vi­ta­bil­men­te cresce.

Gli effetti del debito tecnico cor­ri­spon­do­no, a grandi linee, alle con­se­guen­ze dei prestiti fi­nan­zia­ri. Se il debito non viene ripagato re­go­lar­men­te e pun­tual­men­te, maturano interessi, che si ma­ni­fe­sta­no in un ral­len­ta­men­to dello sviluppo, in un calo della pro­dut­ti­vi­tà e in un aumento dei costi.

È pertanto nell’interesse dei clienti eseguire una gestione e un mo­ni­to­rag­gio della qualità estesi e a lungo termine dopo lo sviluppo del software, al fine di evitare che una rapida ed economica rea­liz­za­zio­ne e pro­du­zio­ne dei prodotti risulti in delle cor­re­zio­ni di errori costose o in un arresto nello sviluppo.

Il debito tecnico non può essere com­ple­ta­men­te escluso a causa delle nuove tec­no­lo­gie e del cam­bia­men­to degli approcci nello sviluppo del software. Inoltre, nella maggior parte dei casi, il debito tecnico viene ad­di­rit­tu­ra accettato al fine di pub­bli­ca­re programmi e ap­pli­ca­zio­ni in modo rapido e regolare. Tuttavia, esistono misure pre­ven­ti­ve per evitare o ridurre l’emergere o la crescita del debito:

• In­tro­dur­re processi stan­dar­diz­za­ti per il re­fac­to­ring e la gestione della qualità
• Uti­liz­za­re strumenti co­stan­te­men­te ag­gior­na­ti per la mi­su­ra­zio­ne e l’analisi degli errori
• Pro­muo­ve­re una co­no­scen­za tecnica at­tra­ver­so una for­ma­zio­ne continua, che tenga il passo con gli sviluppi in­for­ma­ti­ci oltre a de­ter­mi­na­re la com­po­si­zio­ne del team in base alle qua­li­fi­che
• Or­ga­niz­za­re or­di­na­ta­men­te un codice con l'uso di sud­di­vi­sio­ni in classi e metodi chiari, e scriverlo in modo com­pren­si­bi­le per pro­gram­ma­to­ri nuovi o esterni
• Definire chiare re­spon­sa­bi­li­tà e funzioni al­l'in­ter­no dei team per evitare duplicati, ri­don­dan­ze e fasi di lavoro con­tro­pro­du­cen­ti
• Mantenere ag­gior­na­ta l‘ar­chi­tet­tu­ra in­for­ma­ti­ca at­tra­ver­so il mo­ni­to­rag­gio costante, la mi­su­ra­zio­ne e la garanzia della qualità