Il tutto è partito dal blog di Jeff che rimanda ad una metafora divertente, chiamata "technical debt", in sostanza si parla di Technical Debt quando nella realizzazione di un software si sceglie la strada "quick and dirty" invece di una strada più ragionata.
Le ragioni per avere un debito di questo tipo sono molte, alcune sono ragionevoli, come ad esempio la necessità di uscire nel mercato con un prodotto prima della concorrenza, oppure se il cliente ha una deadline tassativa che bisogna a tutti i costi rispettare e si è in ritardo, oppure si sta realizzando una applicazione che deve solo "sondare il mercato" e quindi si vuole valutare l'interesse del pubblico, per poi ripensare tutto daccapo se il gioco vale la candela. Come ogni debito, anche quello "tecnico" usato coscienziosamente porta vantaggi.
Purtroppo esistono invece ragioni pessime per incorrere in questo tipo di debito, la peggiore è una mancata stima del tempo necessario per fare il software.
Il problema è che, come tutti i debiti, anche quello "tecnico" ha i suoi interessi, e qualsiasi sia la ragione per cui lo si è contratto, si deve poi prevedere di spendere del tempo per pagarlo. Purtroppo in molti casi si accumula solamente, fino ad arrivare al punto, che il costo degli interessi non è più sostenibile, ed il costo di aggiungere una nuova feature o correggere un bug diventa enorme, perchè il software è solamente composto di parti "quick and dirty".
E' necessario allora che ogni realtà che produca del software si abitui a considerare il debito tecnico alla stessa stregua di quelli di tipo monetari. Non penso che nessuna ditta si sogni di continuare ad aprire mutui con le banche per hardware o materiale per ufficio, aumentando cosi costantemente il proprio debito; le realtà con una sana amministrazione controllano infatti con attenzione l'entità del proprio indebitamento, in modo da trarne i maggiori benefici.
Per cui è bene fermarsi un attimo, valutare i propri debiti tecnici ed iniziare a prevedere di pagarli prima che il loro costo diventi veramente insostenibile.
Alk.
Tags: Technical Debt Programming