Il debito tecnico nelle piccole aziende di software

Ward Cunningham (il primo sviluppatore di wiki) nel 1992 ha concepito il concetto di debito tecnico. Si riferisce allo sviluppo extra (e quindi extra-costo) nella programmazione che deriva dalla scelta di una soluzione facile a breve termine invece di adottare la migliore soluzione complessiva. Nel suo blog Philippe Kruchten riporta una definizione del debito tecnico (qui).
Il debito tecnico può essere paragonato a un debito finanziario: se non viene onorato, genera interesse che aumenta il debito stesso, rendendo più costoso implementare miglioramenti in seguito. Consideriamo la situazione di affrontare la progettazione di un software (o parte di esso) con due soluzioni possibili: una che è rapida e semplice, ma implica modifiche future, mentre l’altra è ottima, ma richiede più tempo e sforzi. In fase di sviluppo, l’approccio rapido e semplice al rilascio del codice equivale a contrarre un debito, che genera l’extra-costo degli interessi, ovvero il lavoro di sviluppo extra in futuro (che tra l’altro comporta l’aggiornamento della documentazione). Esistono cause comuni ben note del debito tecnico, ma soprattutto nelle piccole società di software le più frequenti tra esse 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. A volte una certa quantità di debito tecnico è inevitabile, perché il time to market lo richiede davvero, ma questo deve essere ben distinto da situazioni in cui semplicemente un progetto è stato concepito per essere sviluppato con vincoli non realistici. Il proprietario della piccola software house tende solitamente ad essere spaventato dalla scelta della soluzione migliore, perché comporta un maggiore investimento finanziario in termini di costi. Questo perché è sempre economicamente intimidito dagli orizzonti temporali di medio-lungo termine. Ma ciò accade, tuttavia, poiché il costo del refactoring non viene mai considerato nel costo dello sviluppo. Questa è la formula che il proprietario della piccola impresa ha fissa in mente (ok, semplificata, ma rende l’idea):

Guadagno = Selling_Price – Costi = Selling_Price – (man_days * daily_salary)

Ma dovrebbe prendere in considerazione un’altra formula più corretta:

Guadagno = Selling_Price – Costi = Selling_Price – (man_days * daily_salary) = Prezzo di vendita- [(development_time + time_for_refactoring) * daily_salary]

Quindi, quando il tempo per il refactoring aumenta più della diminuzione dei tempi di sviluppo, la soluzione semplice e veloce è meno conveniente economicamente, è abbastanza ovvio!