Idea principale

Non tutto ciò che si chiama debito tecnico lo è davvero. Un codice mal strutturato, un'architettura debole, una complessità nota da anni, un rischio latente: sono disagi. Esistono, pesano, ma non hanno alcuna scadenza e nessuno li paga a una data.

Il debito compare nel momento in cui l'azienda decide di saldarlo. È questa decisione a creare l'oggetto: fissa un importo — il costo dell'intervento —, un beneficiario e un momento. Prima, non c'è nulla da mettere a bilancio; dopo, c'è un tema di prodotto come un altro, confrontabile con le funzionalità e messo in concorrenza con esse nelle scelte di priorità.

Ciò che di solito fa scattare questa decisione è un ribaltamento dei costi: il disagio diventa più caro da sopportare che da risolvere — perché blocca una strategia, rallenta molto il team, espone a un rischio, degrada la qualità percepita dal cliente o impedisce un cambiamento importante del prodotto.

Perché è importante

Disinnesca una conversazione che gira in tondo tra sviluppatori e prodotto. Finché il debito viene presentato come uno stato del codice, se ne discute in termini di pulizia, e il prodotto non ha alcuna presa. Ridefinito come decisione di saldarlo, se ne discute in termini di costo e diventa oggetto di scelta.

Spiega anche perché gli inventari del debito non producono quasi mai lavoro: censiscono disagi, e un disagio non chiede niente a nessuno.

Sfumature e limiti

La ridefinizione ha un rovescio: dà al prodotto il diritto di non decidere mai, e quindi di lasciar accumulare un rischio finché non diventa un incidente. Il disagio non trattato non è gratuito, semplicemente non viene contabilizzato.

E il ribaltamento dei costi è difficile da stabilire prima che si manifesti — il rallentamento del team si constata meglio a posteriori che nel momento in cui bisognerebbe decidere.

Domande aperte

• Quali segnali annunciano il ribaltamento dei costi abbastanza presto perché la decisione di saldare preceda l'incidente?