Definizione breve

Debolezza di progettazione o di architettura di un software che l'azienda ha deciso di trattare, e che per questo ha un costo di rimborso e un posto tra le priorità. Finché questa decisione non è presa, la debolezza resta un disagio o un rischio latente.

Definizione dettagliata

Nell'uso corrente, la parola copre tutto ciò che uno sviluppatore rimpiange in un codice esistente: una vecchia scorciatoia, un'architettura debole, una complessità accumulata, una libreria obsoleta. L'analogia finanziaria è puramente descrittiva — si parla di debito per dire che qualcosa costerà più avanti, senza che vengano nominati un creditore, una scadenza o un importo.

Negli articoli di questo blog, la parola è riservata a ciò che è passato attraverso una decisione. Una debolezza nota da anni, che nessuno ha messo in programma, non è un debito: non ha né data, né costo deciso, né responsabile del rimborso. Lo diventa quando l'azienda giudica che il costo di conviverci supera il costo di risolverla — 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.

L'uso sul campo diverge nettamente dal senso adottato qui: nella pratica, «abbiamo del debito» designa uno stato permanente del sistema, e non fa scattare nulla. Il senso adottato qui fa della parola uno statuto che si acquisisce, non una constatazione che si ripete.

Uso nel dominio

Revisione delle priorità tra un tema di prodotto e un tema tecnico, argomentazione di uno sviluppatore davanti a un comitato, decisione di far entrare un tema tecnico nella roadmap, definizione di una strategia di intervento distinta dalla gestione quotidiana dei bug.

Sinonimi e varianti

«il debito» in forma abbreviata · «debito architetturale» quando la debolezza è strutturale · «disagio tecnico» e «rischio latente» per lo stato precedente alla decisione.

Da non confondere con

• Difetto — scarto tra il comportamento atteso di un software e il suo comportamento reale; il debito non ha un comportamento difettoso visibile, pesa sull'evoluzione.
• Policy zero bug — regime che vieta di conservare un difetto noto senza una decisione; riguarda gli scarti di comportamento, mai le debolezze di progettazione.
• Roadmap — vista dei grandi temi impegnati, preparati e possibili; il debito tecnico vi compare solo dopo la decisione di intervento.
• Dette de compréhension — scarto tra ciò che un team ha prodotto e ciò che sa di ciò che ha prodotto; si paga con l'incapacità di decidere cosa riprogettare, mentre il debito tecnico si paga con il lavoro di riprogettazione.
• Refactoring — intervento di miglioramento interno del codice senza cambiamento di comportamento; è un mezzo di rimborso, non il debito stesso.
• Complessità essenziale — difficoltà intrinseca al problema trattato, che nessun lavoro di architettura può eliminare.
• Reconstructibilité — proprietà di un sistema che un team saprebbe rifare altrove a partire dai suoi contratti, dalle sue regole di business e dai suoi test; qualifica ciò che si sa dire del sistema, non la qualità della sua progettazione.
• Dette de compréhension — scarto tra ciò che un sistema fa e ciò che il team che ne risponde sa spiegare; riguarda la testa di chi lo mantiene, mentre il debito tecnico riguarda lo stato del codice, e non ha bisogno di alcuna decisione per esistere.

Esempi

Un'architettura debole, nota da tempo, che non impedisce a nessuno di rilasciare: disagio, non debito.

La stessa architettura, il giorno in cui blocca un progetto strategico e l'azienda decide di rimetterci mano: debito, con un posto da trovare tra le priorità.

Ambiguità / dibattiti

L'analogia finanziaria è contestata: il debito presuppone un prestito volontario, mentre gran parte di ciò che la parola copre si è accumulata senza una scelta, per ignoranza o per vincoli di tempo. Alcuni propongono di riservarne l'uso alle scorciatoie deliberate.

Seconda oscillazione, più operativa: se il debito tecnico vada contato nella capacità del team o tra i temi della roadmap. Circolano entrambe le risposte, e non chiamano in causa lo stesso arbitro.