Home
Sull’orlo del fallimento

23 Febbraio 2012

Sull’orlo del fallimento

di

Vantaggi – relativi – e problematiche – spesso più importanti dei vantaggi – del ricorrere a soluzioni software sporche maledette e subito al posto di fare la cosa giusta.

Se c’è una metafora estremamente efficace per fare il punto sullo stato di realizzazione di un progetto software, è il debito tecnico: un progetto software accumula debito tecnico quando per implementare una nuova funzionalità si sceglie la strada più rapida e “sporca” a scapito di quella che avrebbe prodotto codice di migliore qualità.

Come nella vita reale, contrarre un debito non è necessariamente un male: centrare un particolare obiettivo di time-to-market o assecondare le richieste di un cliente possono portare un vantaggio tale da giustificare un debito tecnico. Però anche sul debito tecnico si pagano interessi – tipicamente in termini di maggiore difficoltà nell’implementazione di nuove funzionalità – che in alcuni casi possono diventare così rilevanti da far “fallire” il progetto.

Come evitare di far entrare il mio progetto nella spirale della crisi del debito? Quali sono le ricette per il risanamento?

Dice Martin Fowler del debito tecnico maturato inconsapevolmente:

The point is that while you’re programming, you are learning. It’s often the case that it can take a year of programming on a project before you understand what the best design approach should have been. Instead what you find is that the moment you realize what the design should have been, you also realize that you have an inadvertent debt.

Quadrante del debito tecnico di Martin Fowler

Martin Fowler ha schematizzato il debito tecnico in quattro differenti tipologie.

Ispezionare il codice del progetto è sicuramente il primo passo: visto che per il debito introdotto inconsapevolmente c’è poco da fare, andrà minimizzato quello introdotto intenzionalmente.

Il secondo passo è fornire agli sviluppatori strumenti che restituiscano feedback istantanei sulla qualità del codice che scrivono (codice duplicato, metodi troppo lunghi, unit test falliti…), ma che permettano anche di stimare il debito tecnico accumulato (come ad esempio fa Sonar).

Il terzo passo, forse quello più importante, è prendersi il tempo (o il coraggio) di spiegare a chi vi chiede di implementare l’ennesima funzionalità in fretta e furia che così facendo sta trascinando il progetto verso la “bancarotta” . Uno sviluppatore che non consegna nuove funzionalità per qualche settimana non sta necessariamente cazzeggiando su Facebook o su Stackoverflow, ma molto probabilmente fatica per abbattere il debito tecnico accumulato dal software sul quale sta lavorando.

Ward Cunningham – l’inventore del Wiki – ha elaborato il concetto di debito tecnico come metafora:

L'autore

  • Andrea C. Granata
    Andrea C. Granata vanta oltre 25 anni di esperienza nel mondo dello sviluppo software. Ha fondato la sua prima startup nel 1996 e nel corso degli anni si è specializzato in soluzioni per l'editoria e il settore bancario. Nel 2015 è entrato a far parte di Banca Mediolanum come Head of DevOps, ruolo che oggi ricopre per LuminorGroup.

Vuoi rimanere aggiornato?
Iscriviti alla nostra newletter

Novità, promozioni e approfondimenti per imparare sempre qualcosa di nuovo

Gli argomenti che mi interessano:
Iscrivendomi dichiaro di aver preso visione dell’Informativa fornita ai sensi dell'art. 13 e 14 del Regolamento Europeo EU 679/2016.