Seconda di due puntate sulle otto Leggi di Lehman. Qui affronto le quattro che parlano di persone e non di codice: il ritmo di lavoro utile che resta costante nel tempo, la quantità limitata di novità che sviluppatori, assistenza e utenti riescono ad assorbire per volta, l’autoregolazione che riporta il team sulla sua media storica, e il software come sistema a feedback, dove la regola introdotta per ridurre i bug finisce per aumentarli.

Che il doppio delle persone non produca il doppio del lavoro lo diceva già Brooks. Lehman dice qualcosa di più scomodo: il tetto esiste, ogni persona aggiunta alza il ritmo meno della precedente, e a fissare quel tetto è l’architettura del sistema, non il budget. Le leggi si piegano solo dove ci sono tanti pezzi separati su cui lavorare in parallelo e nessun limite a chi ci lavora, come nel kernel di Linux e nei contributi a DelphiMVCFramework.

Chiude con quattro contromisure concrete: pianificare sul ritmo misurato e non su quello desiderato, togliere l’attrito prima di assumere, rilasciare a lotti piccoli e frequenti, governare misurando i numeri invece che per decreto. Più il ponte con il pensiero lean, da Taiichi Ohno in Toyota allo sviluppo software.

Se non hai ascoltato la prima parte, è la puntata Le Leggi di Lehman (parte 1): perché il software invecchia anche se non lo tocchi: conviene partire da lì.

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. Sul pensiero lean applicato al codice c’è il libro Lean Thinking per sviluppatori software impegnati.

Fonti: Meir M. Lehman e Laszlo Belady, leggi sull’evoluzione del software (1974-1996), voce Lehman’s laws of software evolution su Wikipedia. Fred Brooks, “The Mythical Man-Month” (1975). Michael W. Godfrey e Qiang Tu, “Evolution in Open Source Software: A Case Study” (2000), sulla crescita super-lineare del kernel Linux concentrata nei driver.

Per formazione e consulenza: professionals@bittime.it.

A cura di Daniele Teti e bit Time Professionals.

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.

In questa puntata racconto come l’ecosistema Delphi (con MCP, il Model Context Protocol, e la libreria open source mcp-server-delphi) renda possibile un agente AI embedded, sicuro e “Man-in-the-Loop”: read-only per analizzare e pianificare, ma fermo in attesa di firma umana su ogni azione dispositiva.

Per CTO, Software Architect, Lead Developer, IT Decision Maker.

Approfondimenti: l’articolo Beyond MCP: AI agentica in Delphi, la pagina del progetto MCP Server per Delphi e la libreria open source mcp-server-delphi.

A cura di Daniele Teti e bit Time Professionals.

Dopo oltre venticinque anni di programmazione, come CEO e CTO di bit Time Professionals, Embarcadero MVP e autore principale di DelphiMVCFramework e di otto libri tecnici, apro “While True Do;”: non un monologo, ma un punto di partenza per confrontarsi e tornare, tutti, con qualcosa di concreto.

Ogni puntata affronta un tema tecnico preciso (architetture software, AI nei sistemi gestionali, pattern enterprise) senza fronzoli, sempre con la consapevolezza che la soluzione perfetta, buona per ogni caso, non esiste. A volte dentro l’ecosistema Delphi, a volte in Python, a volte oltre.

Per Lead Developer, Software Architect, CTO: chiunque costruisca software destinato a durare.

A cura di Daniele Teti e bit Time Professionals.