> ## Content Index > Fetch the complete content index at: https://www.cowsayso.com/llms.txt > Use this file to discover other available public pages before exploring further. # «È facile, cinque minuti»: come una piccola modifica finisce in una riscrittura dell’architettura - URL: https://www.cowsayso.com/it/e-facile-cinque-minuti/ - Published: 2025-09-30T07:00:00.000Z - Updated: 2026-11-08T21:38:26.000Z - Description: Un numero di telefono in fattura. Cinque minuti, hai detto. Una mucca che abita nella tua testa fa i conti: per due, unità successiva. Dieci ore, venti giorni, quaranta settimane… Storia di come sottovalutiamo le modifiche al software. - Author: Vittorio Scala - Tags: Software Engineering, #skimmed, #it Lunedì, 9:12\. Il Dott. Brambilla si appoggia alla tua scrivania con il sorriso di chi sta per chiedere una cosa piccola. «Senti, possiamo mettere il numero di telefono del cliente nel PDF della fattura? La contabilità vuole chiamarli quando non pagano.» Non alzi nemmeno gli occhi. «Certo. È facile. Cinque minuti.» E da qualche parte nella tua testa, dietro gli occhi, qualcosa di grosso e bianco e nero apre lentamente un occhio. > 🐄 *Muuu. Hai appena detto «cinque minuti»? Prima di aprire il codice? Oh, qui ci si diverte.* ## 9:13 · La mucca fa i conti Ogni programmatore ce l’ha: una vocina che la sa più lunga. La tua è una mucca, e ha una regola. Non ha un autore noto: i programmatori se la tramandano come una ricetta di famiglia, e appartiene alla stessa famiglia della legge di Murphy («se qualcosa può andare storto, lo farà», nata in una base aerea americana alla fine degli anni Quaranta). La regola dice: **prendi la stima, moltiplicala per due e passa all’unità di misura successiva.** > 🐄 *Cinque minuti, per due, unità successiva: dieci ore. Sono generosa e non la applico due volte. Per ora.* 🐄 Dire «cinque minuti» prima di aver aperto il codice. **Sbagliato.** La stima data prima di guardare non è una stima, è un desiderio. ## 9:40 · Dove abita il numero di telefono? Apri la tabella delle fatture. Ragione sociale, partita IVA, indirizzo. Telefono no. I numeri di telefono abitano nel CRM, un altro sistema, copiati ogni notte da uno script di sincronizzazione che nessuno ha più aperto da quando è stato scritto. E nel CRM alcuni clienti hanno tre numeri di telefono. Alcuni nessuno. Uno ha, nel campo telefono, «chiamare Gianni dopo le 15». > 🐄 *Quale numero va in fattura? Non guardare me, sono una mucca. Vai a chiederlo a Brambilla. Ah. Ti dirà «quello giusto».* Ti dice «quello giusto». Douglas Hofstadter l’ha messo per iscritto nel 1979, in *Gödel, Escher, Bach*: ci vuole sempre più tempo del previsto, anche tenendo conto della legge di Hofstadter. È l’unica legge che sa già che l’avete letta. 🐄 Quale numero di telefono va in fattura? **Dipende.** Ed è proprio questo il punto: non è una domanda tecnica, è una decisione di business. La risposta va presa prima di scrivere il codice, non dopo. ## 11:30 · Il file che nessuno tocca Il PDF lo produce una libreria che era vecchia già quando è stata installata. Il modello sta in un file che comincia così: ```python # fattura_pdf.py # NON TOCCARE - Marco 2014 # (se lo tocchi, si rompono anche le bolle) ``` Pensi: già che ci sono, aggiorno la libreria. Aggiorni la libreria. Le fatture vengono bene. Le bolle di consegna adesso escono in Times New Roman, al contrario. > 🐄 *Dieci ore, per due, unità successiva: venti giorni. Non fare quella faccia. Il file di Marco non l’ho toccato io. L’hai toccato tu.* Anche per questa sensazione c’è un nome. Tom Cargill dei Bell Labs l’ha detto meglio di tutti, e Jon Bentley l’ha reso famoso nel 1985: il primo 90 per cento del codice richiede il primo 90 per cento del tempo di sviluppo. Il restante 10 per cento del codice richiede l’altro 90 per cento. 🐄 Aggiornare una libreria «già che ci sono» nel mezzo di una piccola modifica. **Sbagliato.** Una modifica alla volta. Altrimenti, quando qualcosa si rompe, non saprai con quale prendertela. ## Martedì · Entra in scena la contabilità La contabilità legge la tua fattura di prova e ha una sola domanda: cosa succede alle fatture vecchie? Se qualcuno ristampa una fattura di marzo, deve uscire esattamente com’è stata spedita a marzo. Senza il numero di telefono. O con il numero che avevano a marzo? Quindi adesso servono modelli con le versioni. E il numero di telefono va salvato insieme alla fattura nel momento in cui viene emessa, non letto al volo dal CRM. > 🐄 *Visto? Il software non è mai finito, continua solo a cambiare. Due signori di nome Lehman e Belady l’hanno scritto nel 1974: un sistema in uso va adattato di continuo, e ogni modifica lo rende più complesso, a meno che qualcuno non faccia il lavoro per semplificarlo. Indovina chi è quel qualcuno.* 🐄 Chiedere a chi usa davvero il documento prima di cambiarlo. **Giusto.** La contabilità ha trovato il vero requisito in quattro minuti. Quattro minuti veri. ## Mercoledì · Il diagramma sulla lavagna Disegni quello che hai trovato. Il modulo fatture legge direttamente la tabella dei clienti. La sincronizzazione del CRM scrive in quattro tabelle diverse. Le bolle condividono metà del codice del modello. Tutto tocca tutto. E arriva il pensiero, bellissimo e terribile: *per farlo come si deve, bisognerebbe riscrivere tutto. Un vero servizio clienti, veri modelli di documento, una vera architettura.* > 🐄 *Venti giorni, per due, unità successiva: quaranta settimane. Vuoi che lo rifaccia? Ottanta mesi. Quasi sette anni. Per un numero di telefono. Muuu.* ```text stima ×2 e unità successiva 5 minuti → 10 ore 10 ore → 20 giorni 20 giorni → 40 settimane 40 settimane → 80 mesi (≈ 6 anni e 8 mesi) ``` Daniel Kahneman e Amos Tversky gli hanno dato un nome nel 1979: la fallacia della pianificazione. Stimiamo immaginando come andrà *questo* lavoro se tutto fila liscio, e ignoriamo come sono andati davvero i lavori simili. Chiunque abbia mai detto «cinque minuti» l’ha fatto. E per la voglia di riscrivere tutto c’è un famoso racconto ammonitore. Nell’aprile del 2000 Joel Spolsky scrisse che riscrivere il codice da zero è «il peggior errore strategico che un’azienda di software possa fare», citando Netscape: quando la versione 6.0 arrivò alla prima beta pubblica, erano passati quasi tre anni dalla versione 4.0\. Una versione 5.0 non è mai esistita. 🐄 Riscrivere tutta l’architettura per aggiungere un numero di telefono in fattura. **Sbagliato.** Il numero arriverebbe fra circa sette anni. La contabilità ha fatture non pagate adesso. ## Giovedì · Il piano della mucca > 🐄 *Bene. Ascolta la mucca. John Gall l’ha scritto nel 1975: un sistema complesso che funziona è sempre nato da un sistema semplice che funzionava. Quindi facciamo la cosa semplice che funziona, e la lasciamo evolvere.* Il piano sta su un post-it: - Brambilla e la contabilità scelgono **un** numero: il referente per la fatturazione. - Quando la fattura viene emessa, il numero viene **salvato con la fattura**. Le fatture vecchie restano com’erano. - Una **nuova versione del modello** accanto a quella vecchia. Il file di Marco resta intatto, per rispetto. - L’aggiornamento della libreria torna da dove è venuto: un lavoro a parte, per un altro giorno. - La grande pulizia dell’architettura finisce in un file chiamato DECISIONI, divisa in piccoli passi, da fare uno alla volta insieme al lavoro normale. Venerdì alle 16:00 parte la prima fattura con il numero di telefono. Tempo totale: poco meno di tre giorni di lavoro. Più di cinque minuti, molto meno di sette anni. 🐄 Fare la modifica più piccola che funziona davvero, e scrivere quella grande per affrontarla un po’ alla volta. **Giusto.** Le architetture migliorano così: un piccolo passo alla volta, non con una riscrittura eroica. ## Venerdì, 17:55 · Di nuovo Brambilla Il Dott. Brambilla torna, entusiasta. «Lavoro magnifico. Senti, già che ci siamo, possiamo aggiungere anche l’email? È facile. Cinque minuti.» > 🐄 *Muuu.* 🐄 Morale: non esistono modifiche da cinque minuti, esistono solo modifiche che non hai ancora guardato. Guarda il codice prima di stimare, chiedi al business prima di programmare, cambia una cosa alla volta, e quando ti viene voglia di riscrivere tutto fai invece la cosa più piccola che funziona. E raddoppia le stime. Poi passa all’unità successiva. La mucca ha parlato, e la mucca è legge. Muuu. 🐄 Fonti I personaggi e la storia sono inventati. Le leggi sono vere. - [Wikipedia, “Murphy’s law”](https://en.wikipedia.org/wiki/Murphy%27s%5Flaw?ref=cowsayso.com) - [Wikipedia, “Hofstadter’s law”](https://en.wikipedia.org/wiki/Hofstadter%27s%5Flaw?ref=cowsayso.com) - [Wikipedia, “Ninety–ninety rule”](https://en.wikipedia.org/wiki/Ninety%E2%80%93ninety%5Frule?ref=cowsayso.com) - [Wikipedia, “Lehman’s laws of software evolution”](https://en.wikipedia.org/wiki/Lehman%27s%5Flaws%5Fof%5Fsoftware%5Fevolution?ref=cowsayso.com) - [Wikipedia, “Planning fallacy”](https://en.wikipedia.org/wiki/Planning%5Ffallacy?ref=cowsayso.com) - [Wikipedia, “John Gall (author)”](https://en.wikipedia.org/wiki/John%5FGall%5F%28author%29?ref=cowsayso.com) - [Joel Spolsky, “Things You Should Never Do, Part I” (2000)](https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/?ref=cowsayso.com) - [Rodney Bliss, “Double It And Move To The Next Unit Of Measure” (an example of the folklore)](https://rodneymbliss.com/2014/11/07/double-it-and-move-to-the-next-unit-of-measure/?ref=cowsayso.com)