Le Leggi di Lehman (parte 1): perché il software invecchia anche se non lo tocchi

Un software in produzione, stabile da anni, che smette di funzionare di punto in bianco, senza che nessuno abbia toccato una riga. Non è un mistero: è entropia che presenta il conto.

Prima di due puntate sulle otto Leggi di Lehman, le osservazioni sull’evoluzione del software formulate tra il 1974 e il 1996. Qui affronto le quattro che parlano del software: cambiamento continuo, crescita continua, qualità percepita in calo e complessità crescente.

Perché un sistema di tipo E, cioè immerso nel mondo reale come un gestionale o un e-commerce, non è mai “finito”. L’unico software che non si rompe mai è quello che vive in un ambiente congelato, senza rete e senza aggiornamenti: ma quella stabilità si paga con l’isolamento totale, e per quasi tutti i sistemi che ci pagano per costruire non è un’opzione. Da quella deriva non si esce, si decide solo quando pagarla e a che prezzo.

La puntata chiude con quattro contromisure concrete: mettere la complessità a bilancio con una quota fissa di ogni sprint, cancellare invece di rifattorizzare, costruire un confine verso tutto ciò che non controlli, farsi avvisare da una build notturna prima che lo faccia il cliente.

Nella seconda parte le altre quattro leggi, quelle che parlano di persone: il ritmo di una squadra che resta lo stesso anche quando assumi, quanta novità riescono a digerire utenti e assistenza, e cosa succede quando provi a mettere ordine per decreto.

Per CTO, Software Architect, Lead Developer, chiunque mantenga sistemi in produzione.

Approfondimenti: l’articolo Leggi di Lehman sull’evoluzione del software spiegate le racconta tutte e otto con scenari pratici, sintomi e contromisure.

Fonti: Meir M. Lehman e Laszlo Belady, leggi sull’evoluzione del software (1974-1996), voce Lehman’s laws of software evolution su Wikipedia.

Per formazione e consulenza: professionals@bittime.it.

A cura di Daniele Teti e bit Time Professionals.