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.
Cause Le cause più comuni (o loro combinazione) che possono portare ad un debito tecnico sono:
Esigenze di mercato, ossia l'urgenza di avere un prodotto da vendere prima possibile, quindi rilasciato prima che le dovute modifiche siano complete. Mancanza di conoscenza del processo, in cui chi prende le decisioni è ignaro delle implicazioni sottostanti (o decide di ignorarle). Mancanza di disaccoppiamento, quando lo sviluppo delle componenti del programma avviene ignorando il paradigma di programmazione modulare o comunque senza l'intento di mantenere basso il legame di dipendenza tra i sottosistemi. Assenza di procedure di test, che incoraggia correzioni di bug "al volo" che non contemplano possibili effetti secondari. Assenza di documentazione, dove il codice viene sviluppato "a braccio", senza documentazione/specificazione dei requisiti. Il lavoro per produrre la suddetta documentazione a posteriori, e la necessaria verifica di corrispondenza con quanto già codificato, rappresenta un debito che occorre prima o poi saldare. Mancanza di collaborazione, causa di degrado dell'efficienza del processo di sviluppo. Un'altra motivazione potrebbe ascriversi ad un affiancamento dei principianti insufficiente o assente da parte delle figure professionali con maggior esperienza. Mancanza di conoscenza, quando il programmatore semplicemente non ha le competenze per scrivere del codice di qualità. Introduzione di dipendenze senza criterio, quando lo sviluppatore introduce nuove tecnologie con costi impliciti di mantenimento (di licenza, di know how, di interoperabilità, di manutenibilità, di supporto esterno) per risolvere "facilmente" i problemi.
In particolare nelle piccole aziende di software le cause più frequenti sono la pressione aziendale (l’urgenza di avere qualcosa da consegnare per il traguardo il prima possibile), la definizione iniziale incompleta (quando lo sviluppo inizia prima di qualsiasi fase di progettazione o comunque quando i requisiti devono ancora essere definiti durante lo sviluppo) e le modifiche alle specifiche dell’ultimo minuto. Tipologie
+ Quadrante del Debito Tecnico Avventato Prudente Volontario "Non abbiamo tempo per progettare" "Dobbiamo rilasciare ora ed occuparci delle conseguenze (più avanti)" Involontario "Cos'è il Layering?" "Ora sappiamo come avremmo dovuto farlo"
Occorre tener conto della distinzione tra tipi di debito tecnico. Martin Fowler nel suo blog di discussione sul tema dello sviluppo, individua il cosiddetto "Quadrante del debito tecnico", distinguendo tra quattro tipi di debito in base a due categorie dicotomiche.
La prima categoria individua la contrapposizione tra debito Avventato e Prudente, mentre la seconda dicotomia è tra debito tecnico Volontario e Involontario.
L'Asse Orizzontale: "Avventato vs. Prudente" (Come viene gestito il debito tecnico). Riguarda la prudenza nella valutazione dei rischi: Impulsività vs. Pensiero Strategico
Asse Verticale: "Volontario vs. Involontario" (Quanto è intenzionale il debito tecnico). Riguarda la conoscenza tecnica e la consapevolezza: Consapevolezza vs. Ignoranza.
Spiegazione dei Quadranti
1. Avventato-Volontario
Esempio: "Non abbiamo tempo per il design." Il team sceglie consapevolmente di accumulare debito tecnico senza valutarne le conseguenze. Porta spesso a un codice mal strutturato, difficile da mantenere e con costi futuri elevati.
2. Prudente-Volontario
Esempio: "Dobbiamo rilasciare ora e affrontare le conseguenze dopo." Il team decide consapevolmente di accumulare debito tecnico, ma pianifica di risolverlo successivamente. Spesso è una scelta strategica per rispettare scadenze aziendali, con un piano di refactoring già in mente.
3. Avventato-Involontario
Esempio: "Cos’è il layering?" Il team non si rende conto di accumulare debito tecnico perché non ha le conoscenze adeguate sulle buone pratiche di sviluppo. È il tipo di debito tecnico più pericoloso, perché porta a un codice caotico e insostenibile.
4. Prudente-Involontario
Esempio: "Ora sappiamo come avremmo dovuto farlo." Il team ha fatto del suo meglio, ma con il tempo ha capito un approccio migliore per progettare il software. Questo tipo di debito tecnico è naturale e inevitabile, perché la conoscenza cresce durante lo sviluppo.
Note
Categoria:Architettura del software