Le leggi di Lehman sull'evoluzione del software: perché il codice marcisce in silenzio (e come reagire)

Il software non si rompe come si rompono i ponti. Un ponte che nessuno tocca può restare in piedi per cinquant’anni o più, e alcuni reggono molto più a lungo. Un codice che nessuno tocca fa l’esatto contrario: marcisce in silenzio. Il mondo che lo circonda si muove (i sistemi operativi si aggiornano, le API vengono deprecate, le normative cambiano, gli utenti pretendono di più) e il programma intatto, congelato così com’è, diventa un po’ meno utile ogni singolo giorno, finché una mattina semplicemente smette di funzionare.

Non è un’opinione. È qualcosa di più vicino alla fisica. Più di cinquant’anni fa, un ricercatore di IBM notò che i grandi sistemi software si comportano secondo schemi sorprendentemente coerenti man mano che invecchiano, e dedicò due decenni a trasformare quelle osservazioni in un insieme di leggi empiriche oggi note come leggi di Lehman sull’evoluzione del software. Descrivono ancora la tua sprint board di oggi, che tu ne abbia mai sentito parlare o no.

Conosciamole davvero: da dove vengono, dove reggono, dove si rompono e, soprattutto, come usarle su progetti reali già da questo trimestre.

Uno studio che, per caso, fondò una disciplina

Meir "Manny" Lehman. Foto: Hilehman, CC BY-SA 4.0, via Wikimedia Commons.

Alla fine degli anni ‘60 IBM stava costruendo OS/360, uno dei progetti software più ambiziosi della sua epoca. Meir “Manny” Lehman, insieme al collega László Bélády, iniziò a studiare la storia delle release di quel sistema, misurando come la sua dimensione, il numero di difetti e l’impegno necessario a modificarlo evolvessero release dopo release. (Bélády e Lehman pubblicarono un primo modello di questo fenomeno sull’IBM Systems Journal nel 1976.)

Quelle che nel 1974 erano tre osservazioni divennero cinque nel 1978 e, entro il 1996, un insieme di otto leggi dell’evoluzione del software. Lehman è oggi ampiamente riconosciuto come il padre dell’intero campo di ricerca dell’evoluzione del software: quando morì nel 2010, la comunità accademica lo commemorò esattamente con queste parole.

Prima di procedere conviene chiarire una sottigliezza, perché è proprio qui che la maggior parte dei riassunti frettolosi diventa imprecisa. Lehman non sosteneva che queste leggi valgano per tutto il software. Classificò i programmi in tre tipi, la classificazione SPE:

• I programmi di tipo S sono definiti interamente da una Specifica fissa. Una funzione che calcola un risultato matematico è corretta o sbagliata rispetto a quella specifica, punto. Non ha mai bisogno di cambiare.
• I programmi di tipo P risolvono un Problema del mondo reale con una soluzione approssimata (pensa a un motore scacchistico) dove il problema è stabile ma la nostra soluzione può sempre migliorare.
• I programmi di tipo E sono Embedded, immersi nel mondo reale. Meccanizzano un’attività umana o di business e diventano parte del mondo che modellano. Una piattaforma bancaria, il checkout di un e-commerce, un sistema di cartelle cliniche. Nel momento in cui vanno in produzione modificano l’ambiente, il che modifica i requisiti, il che costringe il software a cambiare di nuovo.

Le otto leggi descrivono i sistemi di tipo E, e quasi tutto ciò che rilasci per lavoro è di tipo E. Ecco perché queste leggi ti toccano da vicino.

Le otto leggi dell’evoluzione del software a colpo d’occhio

Le leggi non sono nemmeno otto fatti scollegati tra loro. Si rinforzano a vicenda dando vita a un’unica dinamica che spinge il sistema verso il declino, e a un’unica forza contraria che lo trattiene:

Come le leggi si sommano: gli archi rossi spingono verso il declino, il percorso verde è l'impegno deliberato che lo trattiene.

Legge 1 - Cambiamento continuo

“Un sistema di tipo E deve essere continuamente adattato, oppure diventa progressivamente meno soddisfacente.”

Questa è la fondazione. Il valore di un programma di tipo E non è fisso; è definito rispetto a un ambiente in movimento. Tieni fermo il software e il divario tra ciò che fa e ciò di cui il mondo ha bisogno si allarga da solo.

Scenario pratico. La tua app di e-commerce si integra con un gateway di pagamento. Hai scritto quell’integrazione due anni fa e ha funzionato in modo impeccabile e nessuno l’ha più toccata. Poi il gateway annuncia che, entro 90 giorni, abbandonerà il supporto a TLS 1.1 e cambierà il formato della firma dei webhook. Non hai scritto un solo bug, eppure la tua funzionalità “finita” è ora un conto alla rovescia verso un’interruzione in produzione. Il Cambiamento continuo significa che nessun modulo è mai davvero finito; è finito soltanto per ora. La risposta ingegneristica è prevedere un budget per una manutenzione che non sai ancora nominare, e progettare i punti di integrazione (adapter, interfacce versionate) in modo che “il mondo si è mosso” ti costi una piccola modifica anziché una riscrittura.

Legge 2 - Complessità crescente

“Man mano che un sistema di tipo E evolve, la sua complessità aumenta a meno che non si compia un lavoro esplicito per mantenerla o ridurla.”

Nota la formulazione: la complessità cresce per impostazione predefinita. È l’entropia naturale di un sistema sottoposto a cambiamento continuo. Ogni funzionalità aggiunta sotto scadenza, ogni caso speciale innestato su un flusso esistente, ogni “lo sistemiamo dopo” aumenta il disordine strutturale. Ridurre la complessità è l’unica cosa che richiede un impegno deliberato, ed è raramente nella roadmap.

Scenario pratico. Il checkout di una startup nasce come un’unica funzione pulita. Il marketing vuole un percorso per i codici promozionali, e così si aggiunge un if. Poi un percorso per le fatture B2B. Poi uno per le gift card. Poi le eccezioni fiscali regionali. Diciotto mesi dopo, quella funzione è di 600 righe con 40 flag che interagiscono tra loro, e ogni modifica rischia di rompere un percorso che nessuno ricorda più. La Legge 2 ti dice che questo non è stato un problema di disciplina di un singolo sviluppatore distratto: è la traiettoria attesa. La contromisura è trattare il refactoring come una voce ricorrente, non come un’impresa eroica una tantum: un “budget di complessità” fisso (diciamo, il 15–20% di ogni sprint) speso per estrarre moduli, eliminare rami morti e tenere sotto controllo la complessità ciclomatica. I confini dei microservizi e le cuciture della clean architecture sono tattiche, ma il punto strategico è più semplice: se non spendi energia per combattere la complessità, la complessità vince. (È esattamente ciò che il Lean thinking chiama eliminazione degli sprechi: la complessità che non si ripaga più è muda, e potarla è lavoro vero, non overhead.)

Legge 3 - Autoregolazione

“I processi di evoluzione dei sistemi di tipo E sono autoregolanti, con la distribuzione delle misure di prodotto e di processo prossima alla normale.”

È la legge più spesso travisata nei riassunti (non riguarda l’“evoluzione dei grandi programmi”). Lehman osservò che l’evoluzione di un sistema si comporta come un organismo regolato. Misure come la dimensione delle release e il tasso di crescita oscillano attorno a un trend stabile, con picchi e cali che più o meno si annullano a vicenda. Spingi forte in una release e il sistema tende a compensare: un meccanismo di feedback lo riporta verso il suo ritmo di lungo periodo.

Scenario pratico. Un product manager, insoddisfatto di un avanzamento costante, impone una release esplosiva: triplicare lo scope abituale in un solo trimestre. Il team obbedisce. Il risultato è prevedibile per chiunque conosca questa legge: il numero di difetti schizza in alto, la release successiva si riduce drasticamente mentre il team assorbe le conseguenze, e la media delle due release cade quasi esattamente sulla linea di tendenza storica. L’intuizione operativa è un regalo per chi pianifica: la storia stessa delle tue release è uno strumento di previsione. Se le tue ultime dieci release hanno avuto in media ~30 story point di funzionalità nette nuove con un pattern di arrivo dei difetti grosso modo normale, un piano che ne presuppone 90 sta lottando contro la gravità. Usa il trend per fissare aspettative credibili, e tratta una release che lo supera in modo abnorme come un segnale di rischio, non come un trionfo.

Legge 4 - Conservazione della stabilità organizzativa

“Il tasso medio di attività globale effettiva in un sistema di tipo E in evoluzione è invariante per tutta la vita del prodotto.”

Il tasso effettivo al quale viene consegnato cambiamento utile tende a restare più o meno costante per tutta la vita di un progetto e, sorprendentemente, è in larga parte indipendente dalle risorse che gli getti contro. È la legge che si sovrappone alla famosa osservazione di Fred Brooks in The Mythical Man-Month: “aggiungere personale a un progetto software in ritardo lo fa ritardare ancora di più”.

Scenario pratico. Un progetto è in ritardo di tre mesi. L’istinto della dirigenza è aggiungere cinque ingegneri. Ma i nuovi assunti devono imparare il dominio, il team esistente deve smettere di costruire per fare l’onboarding, e il numero di canali di comunicazione nel team cresce in modo quadratico (un team di 5 persone ha 10 collegamenti tra coppie; un team di 10 ne ha 45). Per i due mesi successivi l’output effettivo cala. La Conservazione della stabilità organizzativa afferma che il throughput è governato meno dal numero di persone e più dalla complessità accumulata del sistema e dalla struttura di comunicazione dell’organizzazione. La leva non è più persone: è rimuovere l’attrito: ridurre i tempi di build e deploy, ripagare la complessità della Legge 2, chiarire le responsabilità e ridurre la latenza del feedback in modo che il tasso effettivo di ogni ingegnere salga.

Legge 5 - Conservazione della familiarità

“Man mano che un sistema di tipo E evolve, tutti coloro che vi sono associati (sviluppatori, personale di vendita, utenti) devono mantenere la padronanza del suo contenuto e del suo comportamento per ottenere un’evoluzione soddisfacente. Una crescita eccessiva diminuisce tale padronanza. Di conseguenza la crescita incrementale media resta invariante man mano che il sistema evolve.”

Chiunque sia connesso al sistema (sviluppatori, operatori, personale di supporto e utenti) può assorbire solo una certa quantità di cambiamento per release prima di perdere il controllo su come funziona. Le release che concentrano troppe novità superano questo budget di assorbimento, e ne soffrono la qualità e l’adozione.

Scenario pratico. Un team tenta una riscrittura “big bang”: un anno di lavoro, poi un’unica release che sostituisce il 70% del prodotto in un colpo solo. Al lancio i ticket di supporto si moltiplicano, il team non riesce a capire quale dei mille cambiamenti abbia causato quale regressione, e i power user si ribellano contro un’interfaccia che non riconoscono più. La Legge 5 spiega i redesign di UI fallimentari che tutti ricordiamo, quelli in cui gli utenti hanno lanciato petizioni per riavere la vecchia versione. La disciplina che prescrive è limitare la novità di ogni release, non solo la sua dimensione. Rilascia di continuo in incrementi digeribili, fai girare percorsi nuovi e vecchi fianco a fianco dietro feature flag, e dai alle persone il tempo di costruire familiarità. Il vincolo reale è il cambiamento che il tuo team e i tuoi clienti riescono a capire, non quello che riesci a scrivere.

Legge 6 - Crescita continua

“Il contenuto funzionale di un sistema di tipo E deve essere continuamente incrementato per mantenere la soddisfazione dell’utente nel corso della sua vita.”

Ecco il trio più confuso dell’intero insieme, quindi separiamolo con chiarezza. La Legge 1 (Cambiamento) riguarda l’adattamento di funzionalità esistenti a un mondo che si muove. La Legge 2 (Complessità) riguarda il disordine interno che si accumula. La Legge 6 (Crescita) riguarda la superficie esterna delle funzionalità, che deve espandersi perché le aspettative degli utenti si alzano a cricchetto e non tornano mai indietro. L’extra delizioso di ieri è la base scontata di oggi.

Scenario pratico. Un prodotto SaaS di analytics viene lanciato con cinque integrazioni e i clienti lo adorano. Due anni dopo, i potenziali clienti si tirano indietro nelle call di vendita perché manca il connettore per Snowflake che un concorrente ha aggiunto il mese scorso. Il prodotto non è diventato peggiore: il suo contenuto funzionale ha semplicemente smesso di crescere mentre le aspettative continuavano a salire, e quel divario si legge come declino. La Legge 6 è il motore dietro ogni roadmap di prodotto e ogni lista di funzionalità “table stakes”. L’insidia strategica è che Crescita (Legge 6) e Complessità (Legge 2) tirano in direzioni opposte: ogni funzionalità che aggiungi per soddisfare gli utenti aumenta anche l’entropia. I team maturi lo trattano come un trade-off esplicito, potando le funzionalità a basso valore con la stessa aggressività con cui aggiungono quelle ad alto valore, così che la crescita non ipotechi in silenzio il codice.

Legge 7 - Qualità in calo

“La qualità di un sistema di tipo E apparirà in calo a meno che non venga rigorosamente mantenuto e adattato ai cambiamenti dell’ambiente operativo.”

Nota la parola esatta: la qualità apparirà in calo. Il codice su disco non è cambiato, ma sono cambiati gli standard rispetto ai quali viene giudicato. L’ambiente si è mosso (nuovi browser, nuovi dispositivi, dieci volte il traffico, nuove aspettative di sicurezza) e un programma che era eccellente rispetto all’asticella del 2019 sembra trasandato rispetto a quella del 2026.

Scenario pratico. Un monolite gira in modo affidabile da anni. Nessuno ha introdotto un bug. Eppure gli utenti ora si lamentano che è “lento e goffo”. Cos’è successo davvero: il traffico mobile è passato dal 20% al 70% e l’app non è mai stata progettata per questo; il dataset è cresciuto di 50 volte e le query che erano istantanee ora arrancano; i concorrenti hanno fissato una nuova baseline di reattività. La Qualità in calo afferma che l’antidoto è attivo, non reattivo: devi adattarti continuamente all’ambiente operativo, non limitarti a correggere i difetti segnalati. In pratica questo significa observability che traccia le prestazioni reali rispetto alle aspettative di oggi, una ridefinizione periodica delle baseline di carico e sicurezza, e test automatizzati più pipeline CI/CD che rendano l’adattamento continuo abbastanza economico da farlo davvero. La qualità non è uno stato che raggiungi; è un ritmo che sostieni.

Legge 8 - Sistema a feedback

“I processi di evoluzione di tipo E costituiscono sistemi a feedback multi-livello, multi-loop, multi-agente.”

Questa è la chiave di volta, e riformula tutte le altre. Far evolvere un grande sistema non è una pipeline lineare dal requisito al codice. È una rete di loop di feedback: gli utenti reagiscono alle release, i dati di supporto confluiscono nel prodotto, le decisioni di prodotto vincolano l’ingegneria, la realtà ingegneristica ridisegna la roadmap, la struttura organizzativa plasma l’architettura (con la legge di Conway in agguato lì vicino). Poiché i loop interagiscono, modifiche locali producono effetti non locali, spesso controintuitivi.

Il loop esterno di consegna più i loop interni di correzione tratteggiati: li governi tutti insieme, mai uno in isolamento.

Scenario pratico. Un VP, sperando di alzare la qualità, impone una nuova regola: ogni pull request necessita di tre approvazioni. Il loop previsto dice “più review → meno bug”. Il sistema reale dice altro: le code di review si ingolfano, gli ingegneri accorpano PR più grandi per ammortizzare l’overhead, le PR grandi vengono approvate a scatola chiusa perché nessuno riesce a revisionare con attenzione 2.000 righe, e il tasso di difetti aumenta. La Legge 8 avverte che non si può governare in modo affidabile un sistema a feedback modificando una sola variabile e dando per scontato che il resto resti fermo. La disciplina che richiede è umiltà più misurazione: cambia una cosa, strumenta i loop, osserva gli effetti di secondo ordine e correggi, esattamente la postura empirica e guidata dalle ipotesi che le buone culture DevOps e di miglioramento continuo codificano.

Dove le leggi si piegano, e perché è la parte più utile

Una teoria di 50 anni costruita su un mainframe degli anni ‘60 merita di essere messa alla prova, e di prove ne ha avute parecchie. La sfida più importante è arrivata dall’open source.

Nel 2000, Michael Godfrey e Qiang Tu studiarono il kernel Linux attraverso 96 release dal 1994 al 2000 e trovarono qualcosa che le leggi non prevedevano: il kernel cresceva a un ritmo super-lineare. Questo contraddiceva direttamente il modello di crescita a quadrato inverso che Lehman e Turski avevano derivato dai sistemi commerciali, dove ci si aspettava che la crescita rallentasse man mano che dimensione e complessità rendevano ogni modifica più difficile. Un modello di sviluppo massicciamente parallelo, distribuito a livello globale e basato sul volontariato aveva, a quanto pare, riscritto la curva di crescita. Studi successivi su progetti open source di lunga vita hanno rilevato che le leggi tengono in modo disomogeneo: il Cambiamento continuo si rivela notevolmente robusto, ma altre, come la Conservazione della familiarità e le stesse dinamiche di crescita previste, spesso non reggono una volta che il contesto di un progetto cambia (per esempio, quando entra in fase di manutenzione o cresce attraverso un contributo parallelo di massa).

Perché le leggi si piegano proprio qui? La deviazione non è casuale: dipende da molti fattori, e il primo è che le forze che guidano la crescita delle funzionalità non sono le stesse. Lehman derivò le sue leggi dai sistemi commerciali, dove ciò che viene costruito è in ultima analisi governato dal mercato: le funzionalità vengono aggiunte per vincere trattative, trattenere clienti e proteggere il fatturato, e quella pressione economica plasma la cadenza delle release, lo scope e il costante braccio di ferro tra nuove funzionalità e stabilità. Un kernel open source risponde a un insieme di incentivi completamente diverso. Una funzionalità entra in Linux perché un contributore ne ha bisogno per il proprio hardware, perché un vendor fa l’upstream di un driver, perché i maintainer la giudicano tecnicamente valida e degna dell’onere di manutenzione a lungo termine, e non perché muove un numero di fatturato o appare su una roadmap commerciale. Non c’è nessun trimestre da centrare, nessuna metrica di churn, nessun piano tariffario da proteggere. E con migliaia di contributori indipendenti che lavorano in parallelo, ciascuno per soddisfare un proprio bisogno specifico, la crescita non è strozzata dalla capacità di una singola organizzazione (Legge 4) né da ciò con cui un singolo team riesce a mantenere la familiarità (Legge 5), quindi può correre super-lineare in un modo che i dataset commerciali di Lehman non hanno mai mostrato. I criteri che decidono se una funzionalità debba esistere sono semplicemente diversi da quelli commerciali su cui le leggi erano state calibrate.

Questo riformula l’intero risultato. Diverse leggi di Lehman sono, in fondo, affermazioni sull’organizzazione che produce il software (la sua economia, la sua capacità, i suoi incentivi) tanto quanto sul codice stesso. Cambia il motore che guida il lavoro e il comportamento misurabile cambia con esso. Il kernel Linux non ha infranto le leggi; ha funzionato con un motore diverso da quello che Lehman aveva osservato.

Non è un motivo per scartare le leggi. È il motivo per rispettarle. Le leggi di Lehman sono generalizzazioni empiriche su un regime particolare: sistemi chiusi, sviluppati commercialmente, organizzativamente limitati. Quando cambi il regime in modo fondamentale (l’economia, il parallelismo, il modello di contribuzione), alcune leggi si piegano e altre si spezzano. Sapere quali leggi sono robuste (il cambiamento è inevitabile, la complessità cresce senza impegno, il feedback domina) e quali sono condizionali (la curva di crescita precisa, la cadenza autoregolante) è esattamente il tipo di giudizio che distingue gli ingegneri che citano i principi da quelli che li usano.

L’unica idea da tenere

Togli la formalità e le otto leggi collassano in un’unica, scomoda verità:

Lasciato a sé stesso, perde il passo con il mondo (Legge 1), accumula disordine interno (Legge 2), appare peggiore rispetto a standard crescenti (Legge 7) e affama i suoi utenti della crescita che ormai si aspettano (Legge 6), mentre loop di feedback che non controlli del tutto (Legge 8) resistono ai tuoi tentativi di gestirlo, e il tuo numero grezzo di persone non può comprarti una via d’uscita (Legge 4).

I team che prosperano non sono quelli che sfuggono a queste forze, perché nessuno ci riesce. Sono quelli che le mettono in conto: che prevedono un budget per la manutenzione prima che diventi urgente, che spendono un impegno continuo per combattere la complessità, che dimensionano ogni release su ciò che le persone riescono ad assorbire, che trattano la qualità come un ritmo da sostenere anziché come un traguardo, e che governano il proprio processo misurandone i loop invece di emanare decreti al suo interno.

C’è un nome per questa postura. Se le leggi di Lehman descrivono la malattia (l’entropia che si accumula, la complessità che cresce da sola, la qualità che scivola via mentre il mondo continua a muoversi), allora il Lean thinking è la cosa più simile a una cura che abbiamo: rimuovere senza sosta gli sprechi (muda), mantenere piccola la dimensione dei batch così che le persone non perdano mai il controllo del sistema (che è precisamente la Conservazione della familiarità di Lehman), costruire la qualità fin dall’inizio anziché ispezionarla a posteriori, e lasciare che siano i loop di feedback, non gli editti, a guidare il lavoro (l’ottava legge di Lehman, riformulata come pratica di gestione). Non è un’analogia forzata: i due framework descrivono lo stesso sistema da estremità opposte: uno dà un nome alle forze, l’altro alla disciplina che vi risponde.

Il libro che completa questo articolo

Lean Thinking per Sviluppatori Software Impegnati

Le leggi di Lehman danno un nome alle forze che trascinano ogni codice verso il declino. Questo libro è il manuale sul campo per reagire. Porta i principi Lean di Toyota dentro il codice: taglia gli sprechi invisibili nel tuo processo, mantieni piccoli i batch (la Conservazione della familiarità messa in pratica), costruisci la qualità fin dall'inizio anziché ispezionarla a posteriori, e governa con i loop di feedback invece che con gli editti, il tutto con esempi concreti, metriche DORA e un intero capitolo dedicato al lavoro con gli agenti AI.

Acquista su Leanpub → Scopri di più

Disponibile in italiano su Leanpub.

Lehman si fece insegnare queste lezioni da un sistema operativo per mainframe negli anni ‘70. Il tuo codice distribuito, cloud-native e assistito dall’AI te le sta insegnando di nuovo proprio adesso. L’unica domanda è se stai leggendo il programma del corso, oppure se ti stanno valutando a un esame che non sapevi di star sostenendo.

Punti chiave

• Il declino è la condizione predefinita. Un sistema del mondo reale (di tipo E) lasciato intatto non resta fermo: si allontana progressivamente dal passo del suo ambiente (Legge 1) e sembra perdere qualità (Legge 7).
• La complessità cresce a meno che non la combatti. La Complessità crescente (Legge 2) è entropia; solo un refactoring deliberato la inverte. Mettila a budget, non sperarci.
• Non puoi comprarti una via d’uscita con il numero di persone. La Conservazione della stabilità organizzativa (Legge 4), insieme alla legge di Brooks, implica che il throughput è governato dalla complessità e dalla comunicazione, non dal conteggio grezzo del personale.
• Rilascia cambiamenti che le persone riescono ad assorbire. La Conservazione della familiarità (Legge 5) limita quanta novità un team e i suoi utenti possono reggere per release. I piccoli batch battono le riscritture big bang.
• Continua a crescere, ma pota. La Crescita continua (Legge 6) è obbligatoria per la soddisfazione, eppure ogni funzionalità aumenta la complessità: trattala come un trade-off esplicito.
• Governa i loop, non le variabili. L’evoluzione è un sistema a feedback (Legge 8); cambia una cosa, misura gli effetti di secondo ordine e correggi.
• Le leggi si piegano, quindi usa il giudizio. Tengono in modo disomogeneo nei progetti moderni e open source: sappi quali sono robuste e quali condizionali.

Domande frequenti

Cosa sono le leggi di Lehman sull’evoluzione del software?

Sono otto osservazioni empiriche, formulate da Meir M. Lehman tra il 1974 e il 1996, che descrivono come i sistemi software di tipo E (quelli immersi nel mondo reale) cambino, crescano e si degradino inevitabilmente nel tempo, a meno che non si investa un impegno deliberato per contrastare questa tendenza. L’insieme comprende Cambiamento continuo, Complessità crescente, Autoregolazione, Conservazione della stabilità organizzativa, Conservazione della familiarità, Crescita continua, Qualità in calo e Sistema a feedback.

Cos’è un sistema di tipo E?

Nella classificazione SPE di Lehman, un programma di tipo E è immerso nel mondo reale e meccanizza un’attività umana o di business, come una piattaforma bancaria o il checkout di un e-commerce. A differenza dei programmi di tipo S (definiti da una specifica fissa) e di tipo P (una soluzione approssimata a un problema stabile), un sistema di tipo E modifica l’ambiente stesso che modella, e questo lo costringe a evolvere di continuo. Le otto leggi descrivono i sistemi di tipo E.

Le leggi di Lehman valgono ancora per il software moderno e open source?

In parte. Gli studi di replica hanno rilevato che le leggi tengono in modo disomogeneo. Il Cambiamento continuo è notevolmente robusto, ma altre si piegano non appena cambia il regime di sviluppo. Lo studio di Godfrey e Tu del 2000 sul kernel Linux ha riscontrato una crescita super-lineare che contraddiceva il modello di crescita a quadrato inverso che Lehman aveva derivato dai sistemi commerciali, e studi successivi sul software FLOSS hanno scoperto che leggi come la Conservazione della familiarità spesso non reggono.

Perché la qualità del software sembra calare anche quando nessuno tocca il codice?

A causa della settima legge di Lehman, la Qualità in calo: la qualità di un sistema di tipo E viene giudicata rispetto a un ambiente in movimento. Man mano che browser, dispositivi, volumi di traffico e aspettative degli utenti avanzano, il software lasciato intatto appare progressivamente peggiore, anche se il suo codice non è mai cambiato. L’antidoto è l’adattamento continuo all’ambiente operativo, non il semplice fixing reattivo dei bug.

Perché il kernel Linux non segue la legge della crescita di Lehman?

Perché il kernel si muove su incentivi diversi da quelli dei sistemi commerciali studiati da Lehman. Il suo modello di crescita presupponeva che l’aumento delle funzionalità fosse governato dalla pressione del mercato e del fatturato all’interno di una singola organizzazione di capacità limitata. Nell’open source le funzionalità vengono aggiunte perché i contributori ne hanno bisogno per il proprio hardware, perché i vendor fanno l’upstream dei driver, o perché i maintainer le giudicano tecnicamente valide, e non per centrare un obiettivo di fatturato o una roadmap commerciale. Con migliaia di contributori indipendenti che lavorano in parallelo, la crescita non è limitata dalla capacità di una singola organizzazione, quindi Godfrey e Tu (2000) hanno misurato una crescita super-lineare invece del rallentamento previsto. La legge non ha fallito; il kernel funziona con un motore diverso, perché i criteri che decidono se una funzionalità debba esistere sono diversi da quelli commerciali su cui le leggi erano state calibrate.

Fonti e approfondimenti: Bélády & Lehman, “A Model of Large Program Development,” IBM Systems Journal (1976); Lehman, “Laws of Software Evolution Revisited” (1996); Godfrey & Tu, “Evolution in Open Source Software: A Case Study” (2000); Canfora et al., “In memory of Manny Lehman, ‘Father of Software Evolution’” (2011); e González-Barahona et al., “Studying the laws of software evolution in a long-lived FLOSS project” (2014).