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[1] (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[2].
Tipologie
Quadrante del Debito Tecnico
|
|
Avventato
|
Prudente
|
Volontario
|
"Non si ha tempo per progettare"
|
"Dobbiamo rilasciare ora ed occuparci delle conseguenze (più avanti)"
|
Involontario
|
"Quale Layering?"
|
"Ora sappiamo come avremmo dovuto fare"
|
Occorre tener conto della distinzione tra tipi di debito tecnico. In un blog di discussione sul tema dello sviluppo, l’autore individua il cosiddetto "Quadrante del debito tecnico"[3], 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 ed Involontario.
Note
