Doctorow chiarisce

Nella progettazione del software, il “debito tecnologico” si riferisce a decisioni passate che si rivelano sbagliate con il senno di poi.Per esempio, uno sviluppatore ha deciso di incorporare un protocollo di rete realizzato da un produttore che nel frattempo ha smesso di supportarlo. Ma tutto il prodotto si basa ancora su quel protocollo di sviluppo obsoleto e quindi, a ogni revisione, il team di sviluppo deve lavorare intorno a questo nucleo obsoleto, aggiungendo livelli di compatibilità, circondandolo con controlli di sicurezza che cerchino di rafforzare le difese e via di questo passo. Queste misure di sostegno aggravano il debito, perché ogni revisione successiva deve tenere conto anche di queste soluzioni, esattamente come gli interessi di un prestito subprime fraudolento (…) gli interessi aumentano più velocemente di quanto si possa sperare di poterli ammortizzare. Il team di sviluppo deve dedicare tante risorse alla gestione di questo sistema, complesso quanto fragile, che non ha il tempo di ridefinire il software delle fondamenta e “ripagare il debito” una volta per tutte. In genere, il debito tecnologico si traduce in una bancarotta tecnologica, il prodotto diventa così inaffidabile da collassare in modo catastrofico (C. Doctorow, “Come distruggere il capitalismo della sorveglianza”)