Idea principale

Il legacy si racconta come un'eredità: codice vecchio, decisioni passate, architetture fragili, dipendenze mal documentate, scelte che ieri avevano senso. Presentato così, lo si subisce — lo si eredita e ci si arrangia.

La parte che non si subisce è quella che si sta scrivendo. Un difetto passato a qualcun altro, una specifica vaga accettata senza discussione, un test mai scritto, una regressione ripercorsa a mano sprint dopo sprint, una QA usata come ultima rete, codice consegnato in fretta e mal compreso: ciascuna di queste scelte è una rinuncia con una data, e ciascuna diventa una riga del legacy che il team scoprirà fra due anni.

Ciò che le accomuna non è la fretta. È uno spostamento: la responsabilità della qualità lascia chi poteva ancora esercitarla, e il prodotto conserva la traccia di questo spostamento molto dopo che tutti hanno dimenticato il vincolo che l'aveva motivato.

Perché è importante

Trasforma una fatalità in qualcosa su cui si può decidere. Finché il legacy è un'eredità, richiede piani di risanamento; una volta visto come produzione corrente, diventa la conseguenza di decisioni che si prendono questa settimana, e su cui si può agire senza un budget dedicato.

Fornisce anche un elenco di indicatori anticipatori: i rinvii citati si osservano subito, mentre il loro effetto si vede solo dopo anni.

Sfumature e limiti

Non ogni rinvio è una colpa. Alcuni debiti si contraggono consapevolmente, per una ragione legata al momento, e si ripagano — la differenza sta nel fatto che vengano nominati come tali nel momento in cui li si contrae.

E il legacy non nasce solo dalle rinunce: una tecnologia invecchia, un mercato cambia, un'architettura corretta diventa inadeguata senza che ci sia stato alcun rinvio.

Domande aperte

• Per quanto tempo un debito dichiarato resta un debito prima di diventare, in mancanza di rimborso, una rinuncia come le altre?