← Tutti gli episodi

Perché una modifica semplice ti costa tre mesi
Episodio 8

Perché una modifica semplice ti costa tre mesi

· 00:14:56

Ti sarà capitato. Il gestionale gira da quindici anni, non crasha, i clienti sono contenti. Poi il commerciale chiede una cosa che sembra banale: gli ordini dell’e-commerce devono entrare direttamente nel programma, via API. Apri il codice. Non ci sono bug, i test passano, niente è scritto male. E la stima è di tre mesi.

Debito architetturale: dove se ne vanno quei tre mesi?

Poi ti accorgi che non succede una volta sola. Ogni richiesta appena fuori dall’ordinario costa il doppio, a volte il triplo. Il team lavora, le consegne rallentano, e né i test né i log ti dicono perché.

Adesso aggiungi l’AI. Il codice nuovo arriva più in fretta che mai, pulito e funzionante. Stai ripagando il debito o lo stai facendo crescere più veloce? E prima o poi qualcuno, in riunione, dice la frase: “ormai facciamo prima a riscriverlo da zero”.

Cosa trovi in questa puntata

Parlo del debito architetturale. Parto da un bottone “Conferma ordine” di una form Delphi e da un articolo di David Parnas del 1972. Passo per le Leggi di Lehman delle puntate 2 e 3 e per quello che è successo a Southwest Airlines nel dicembre 2022, poi guardo cosa dicono Gartner e i dati 2026 di GitClear sul codice che scriviamo con l’AI.

In chiusura, quattro cose da cui puoi partire già domattina, anche su un gestionale di vent’anni, e cosa rispondere a chi vuole riscrivere tutto.

Di form Delphi, codice legacy e design pattern ho scritto anche in A Simple start with MVP in Delphi for Win32 e nel webinar Refactoring legacy code to design patterns. Per le API REST in Delphi c’è DelphiMVCFramework. Le altre puntate stanno tutte su while true do;.

Fonti

Se il tuo gestionale è diventato un limite e vuoi un piano per ripulirne l’architettura senza fermare il lavoro, bit Time Professionals fa formazione e consulenza su questo. Scrivici a professionals@bittime.it. Per domande, suggerimenti o correzioni sulla puntata: whiletruedopodcast@bittime.it.

A cura di Daniele Teti e bit Time Professionals.

Fatti chiave

Episodio 8 del podcast "while true do;" di Daniele Teti: il debito architetturale, cioè il debito tecnico che sta nei confini tra i moduli e non nelle righe di codice, e cosa gli succede ora che il codice lo scrive in buona parte l'AI.

  • Episodio 8, durata 14:56, pubblicato il 28/09/2026, in italiano
  • Definizione: il debito di codice sta in un punto preciso e si ripaga in un pomeriggio (l'aliquota IVA scritta a mano in trenta punti); il debito architetturale è un'ipotesi di base sbagliata che sta in tutti i punti (la logica di conferma dell'ordine dentro l'evento di un bottone di una form Delphi, che impedisce di esporla via API all'e-commerce)
  • David Parnas, 1972, "On the Criteria To Be Used in Decomposing Systems into Modules": i confini tra i moduli vanno messi attorno alle decisioni che probabilmente cambieranno
  • Il debito architetturale non produce errori ma lentezza: una modifica da 2 giorni ne richiede 10, gli 8 in più sono gli interessi e si pagano a ogni modifica. Collegamento alle Leggi di Lehman (puntate 2 e 3)
  • Caso Southwest Airlines, dicembre 2022: quasi 17.000 voli cancellati e più di 2 milioni di passeggeri a terra; il software interno di pianificazione degli equipaggi funzionava ogni giorno ma non reggeva la ripianificazione di migliaia di cancellazioni. Il CEO: la crescita dell'azienda aveva superato gli strumenti
  • Gartner (Magic Quadrant for Technical Debt Management Tools 2026, citato da SIG) prevede che entro il 2027 l'80% del debito tecnico sarà architetturale, cioè trasversale a più sistemi o livelli; gli assistenti AI sono sempre più efficaci sul debito di codice
  • GitClear 2026 (dati parziali dell'anno): il codice spostato o riorganizzato è sceso dal 21% delle righe modificate nel 2022 al 3,8%; i blocchi duplicati per milione di righe modificate sono passati da 40,3 nel 2023 a 73,0. L'andamento coincide con la diffusione degli assistenti AI, non ne dimostra la causa
  • Tesi sull'AI: rende più economico ripagare il debito di codice ma fa crescere quello architetturale, perché lavora dentro i confini che trova e aggiunge invece di spostare
  • Quattro consigli: misurare gli interessi (stima contro tempo reale e unit toccate nelle ultime dieci modifiche); rendere i confini verificabili con un controllo sulle clausole uses che fa fallire la build; ripagare un confine alla volta; chiedere all'AI di spostare la logica in una unit comune invece di aggiungerne una copia
  • Riscrivere da zero senza aver capito dove erano i confini sbagliati ricostruisce lo stesso debito nel nuovo sistema
  • Pubblico: CTO, Software Architect, Lead Developer che gestiscono gestionali e sistemi enterprise di lunga vita
  • Autore: Daniele Teti, bit Time Professionals. Feed RSS https://www.danieleteti.it/podcast/feed.xml

Domande frequenti

Qual è la differenza tra debito di codice e debito architetturale?
Il debito di codice sta in un punto preciso, come un valore scritto a mano in trenta posti, e si ripaga in un pomeriggio con un cerca e sostituisci. Il debito architetturale sta nei confini tra i moduli e nelle ipotesi di base del sistema, per esempio la logica di conferma di un ordine dentro l'evento di un bottone: è presente in tutti i punti e non si risolve modificando una riga.
Perché il debito architetturale non si vede?
Perché non produce errori ma lentezza. Il sistema continua a funzionare, però una modifica che in un sistema ordinato richiede 2 giorni ne richiede 10: gli 8 giorni in più sono gli interessi e si pagano a ogni modifica. Diventa evidente quando al sistema si chiede qualcosa per cui non era stato pensato, come è successo a Southwest Airlines nel dicembre 2022.
L'AI riduce o aumenta il debito architetturale?
Secondo Gartner gli assistenti AI sono sempre più efficaci sul debito di codice, e prevede che entro il 2027 l'80% del debito tecnico sarà architetturale. I dati GitClear 2026 mostrano che il codice spostato è sceso dal 21% delle righe modificate nel 2022 al 3,8%, mentre i blocchi duplicati sono quasi raddoppiati. L'AI lavora dentro i confini che trova e tende ad aggiungere codice invece di spostarlo, a meno che non glielo si chieda.
Come si comincia a ripagare il debito architetturale?
Misurando gli interessi: per le ultime dieci modifiche si confrontano la stima iniziale, il tempo reale e le unit toccate. Poi si rendono i confini verificabili con regole che fanno fallire la build, per esempio un controllo sulle clausole uses in Delphi, e si ripaga un confine alla volta, spostando una regola di business in una unit di servizio e facendo passare di lì il resto del programma.