Martin Fowler

Autore e ingegnere del software tra i più influenti nei domini dell'agile, dell'architettura del software e del refactoring, co-autore del Manifesto Agile (2001), autore di Refactoring (1999, seconda edizione 2019) e Patterns of Enterprise Application Architecture (2002), e Chief Scientist di Thoughtworks da 25 anni (intervistato nel podcast The Pragmatic Engineer nell'episodio pubblicato il 19 novembre 2025). ¹

Carriera: dagli inizi accidentali a Thoughtworks

L'ingresso di Fowler nello sviluppo software tra fine anni '70 e inizio anni '80 avviene per una serie di casi fortuiti: ¹

• Dal saldatore al Fortran IV: a scuola riceveva pessimi voti in tutto ciò che riguardava la scrittura, ma era portato per la matematica e la fisica; al tempo stesso era completamente negato per qualsiasi lavoro manuale che richiedesse forza o coordinazione fisica (incapace persino di svitare i dadi arrugginiti della propria auto). Scivolato verso l'elettronica (dove bastava saper tenere in mano un saldatore) e poi verso i computer (dove non serviva neppure quello), prima dell'università lavora per un anno alla UK Atomic Energy Authority (soprannominata Ukulele) programmando in Fortran IV. Dopo una laurea mista in ingegneria elettronica e informatica, scarta l'ingegneria tradizionale — allora poco pagata e di basso status — per l'informatica, prima ancora della diffusione di internet. ¹
• Coopers & Lybrand, Jim Odell e PEK: il primo impiego è nella società di consulenza Coopers & Lybrand (che ribattezza scherzosamente Cheatum and Lightum), dove viene assunto perché è uno dei pochi a conoscere Unix dall'università e deve gestire le workstation su cui gira il software di un piccolo gruppo dedito alla consulenza di information strategy. Quel gruppo — che col senno di poi Fowler giudica avvolto da parecchio snake oil ma anche da ottime idee etichettate sotto il nome allora radicale di object orientation — gli apre le porte della programmazione a oggetti a metà anni '80. Lì incontra il consulente e insegnante americano Jim Odell, pioniere dell'information engineering, che diventa il mentore decisivo dei suoi inizi. Dopo un paio d'anni lascia Coopers & Lybrand per entrare per altri due anni nella minuscola e "folle" azienda da cui provenivano quelle idee, PEK (4 persone nell'ufficio britannico, che era il più grande della società), sperimentando dopo la follia di una grande azienda quella di una piccola. ¹
• Consulente indipendente, USA e Chrysler C3: lasciata PEK giurando che non avrebbe mai più lavorato come dipendente per un'azienda, lavora con successo per tutti gli anni '90 come consulente indipendente (sostenuto da Jim Odell che gli passa molto lavoro), scrive i suoi primi libri e nel 1993 si trasferisce negli Stati Uniti. In quel decennio collabora con Kent Beck in Chrysler sul celebre progetto C3, culla di Extreme Programming (XP). ¹
• L'ingresso in Thoughtworks (25 anni fa): incontra Thoughtworks come cliente mentre affrontano un progetto da circa 100 persone (enorme per loro all'epoca) destinato a schiantarsi (crash and burn); li aiuta a diagnosticare il problema e a salvare il progetto. Colpito dal fatto che — mentre gli altri clienti dicevano "ottime idee, ma troppo difficili da implementare" — Thoughtworks rispondeva "ottime idee, difficili da implementare, ma proviamoci" riuscendoci quasi sempre, accetta l'invito a unirsi a loro "per un paio d'anni", restandovi da 25 anni. ¹

Il ruolo di Chief Scientist e il lavoro oggi

Fin dal giorno dell'assunzione in Thoughtworks porta il titolo di Chief Scientist, scelto dall'azienda perché all'epoca era usato per le figure pubbliche legate alle idee (come Grady Booch, allora Chief Scientist in Rational). Fowler ama ricordare: "non sono capo di nessuno e non faccio alcuna scienza"; paradossalmente, in una Thoughtworks in cui chiunque poteva scegliersi liberamente il proprio job title, lui fu l'unico obbligato ad accettare un titolo che trovava pretenzioso (avrebbe preferito flagpole, battering ram o soprattutto loudmouth). ¹

Oggi non scrive più codice di produzione da lungo tempo, con l'unica ironica eccezione del codice che fa girare il proprio sito web, dove continua a generare stack trace. Il suo lavoro primario — e il suo principale canale di apprendimento — consiste nel portare buoni articoli sul suo sito, lavorando a stretto contatto nell'editing con i colleghi che operano ogni giorno sui progetti reali (come Unmesh Joshi e Birgitta) per aiutarli a distillare ed esprimere le proprie lezioni al pubblico più ampio possibile. Segue inoltre costantemente Simon Willison e Kent Beck (da cui scherza di aver "parassitato" idee per tutta la carriera e che considera un mentore anche tra pari). ¹

Contributi fondamentali

• Refactoring (1999, 2ª ed. 2019): nato dall'osservazione dei minuscoli passi compositi di Kent Beck in Smalltalk a Detroit durante il progetto Chrysler C3 e dal Refactoring Browser del gruppo di Ralph Johnson (costruito da John Brant e Don Roberts all'Università dell'Illinois a Urbana-Champaign); scritto in Java nella prima edizione del 1999 e riscritto in JavaScript nella seconda edizione del 2019. ¹
• Patterns of Enterprise Application Architecture (2002) e i design pattern: raccolta di oltre 40 pattern (tra cui Lazy Load, Identity Map, Template View). Per Fowler i pattern non sono "medaglie da appuntarsi al petto" infilandone il più possibile in un sistema, ma un vocabolario condiviso (come il greco e il latino in medicina) per discutere con precisione alternative e contesti d'uso; hanno perso slancio proprio per l'abuso fattone, ma restano uno strumento vitale (cita il libro sui pattern dei sistemi distribuiti scritto di recente con Unmesh Joshi). Rispondendo alla tesi di Grady Booch secondo cui i cloud provider (AWS, Google Cloud, con building block già ben architettati come DynamoDB o Postgres gestiti) avrebbero "risolto" l'architettura, Fowler sospetta che esistano comunque pattern per combinare quei blocchi. Osserva inoltre che ogni azienda crea inevitabilmente il proprio gergo interno (come i nomi dei servizi in Uber o in American Express) e che nelle grandi organizzazioni servono fino a tre anni solo per comprendere il panorama dei sistemi: un groviglio non logico perché costruito da umani nel tempo tra cambi di fornitori, simpatie personali e riorganizzazioni. ¹
• Manifesto Agile (2001): scaturito da un incontro in Oregon organizzato da Kent Beck un anno prima (con partecipanti anche esterni a XP come Jim Highsmith) sulla scelta tra mantenere XP ristretto o unire le forze con altri movimenti come Scrum, e culminato nel febbraio 2001 nello Utah (scelto per lo sci su spinta di Alistair Cockburn contro la proposta di Dave Thomas per Anguilla nei Caraibi). Bob Martin insistette per redigere un manifesto, che Fowler sul momento credeva sarebbe stato completamente ignorato ma utile come esercizio per capirsi tra i 17 presenti. Citando l'aforisma di Cockburn ("la tua idea brillante sarà ignorata o fraintesa, e non scegli tu quale delle due"), ricorda che i 4 valori e i 12 principi fotografavano un percorso in divenire ("we are uncovering") e che il vero successo dell'Agile è aver reso accettabile ai clienti lavorare per piccoli incrementi con test e build automatizzate — pratiche rifiutate come anatema nel 2000 — pur restando un'"ombra pallida" della visione originaria (vedi Slice Sottili e Ciclo di Feedback). ¹
• Technology Radar di Thoughtworks: nato oltre dieci anni fa dal Technology Advisory Board voluto dall'allora CTO Rebecca Parsons e dall'idea di Daryl Smith, processo bottom-up da cui emersero anche i microservizi con James Lewis. ¹

Posizioni chiave sull'AI e sull'ingegneria del software

• Non Determinismo del Software: l'AI è il cambiamento più grande della sua carriera, paragonabile al passaggio dall'assembly ai primi linguaggi ad alto livello, ma il salto principale non è l'astrazione bensì il passaggio dal determinismo al non determinismo, che impone di ragionare per tolleranze (come nell'ingegneria strutturale) e di co-costruire astrazioni e notazioni rigorose con l'LLM. ¹
• Slice Sottili e Ciclo di Feedback: il vibe coding elimina il ciclo di apprendimento; per costruire software duraturo bisogna procedere per slice sottili e frequenti trattate come PR di un "collaboratore losco", puntando a ridurre il cycle time anziché ingrandire i batch. ¹
• Refactoring nell'Era AI: con gli LLM che producono rapidamente codice di qualità discutibile e faticano nel brownfield, la disciplina dei piccoli passi che preservano il comportamento diventa ancora più centrale, soprattutto usando l'LLM per guidare strumenti deterministici. ¹
• Spec-Driven Development e Dark Factory Agentica: scrivere una specifica enorme senza guardare il codice ripete l'errore del Waterfall; serve invece la specifica più piccola possibile per fare un passo avanti in loop stretti con verifica umana costante, usando la specifica per affinare l'ubiquitous language (vedi Leading Words e Fondamentali del Software). ¹
• Enterprise, fonti, junior e stato del settore:
• Le enterprise non sono monoliti: la variazione dentro una grande azienda è spesso maggiore di quella tra aziende diverse. Per capire un'organizzazione software bisogna guardare il suo core business: dopo aver visitato le sale di conteggio e pulizia delle banconote della Federal Reserve di Boston (dove non hanno il permesso di toccare gli LLM per la gravità delle conseguenze di un errore), Fowler osserva come i controlli ferrei sul contante spieghino la cautela del loro software, così come la sicurezza dei voli spiega la mentalità delle compagnie aeree, all'opposto della propensione al rischio di una startup senza clienti. ¹
• Riconoscere le buone fonti dall'incertezza: diffida di chi esibisce certezze assolute ("usa sempre i microservizi" o "non usarli mai") o vende ricette pronte (cookbook answers: chi lo fa o non ha capito o sta nascondendo qualcosa, perché vale sempre la lezione ultracinquantennale di No Silver Bullet); si fida invece di chi dichiara i propri dubbi ed esplora i trade-off e il contesto (come il libro dell'autore svedese Jimmy Nilsson nel mondo Microsoft di fine anni '90). ¹
• Consigli ai junior: usare gli strumenti AI ma dare priorità assoluta alla ricerca di buoni senior che facciano da mentori (poiché a un junior manca il metro per valutare l'output) e interrogare sempre l'AI sulle sue fonti e sul perché di una risposta, ricordando che è credulona (gullible) e mente di continuo. ¹
• Tassi zero, bolla AI e competenza core: la depressione del mercato del lavoro tech (centinaia di migliaia di licenziamenti e la frenata di Thoughtworks dopo una crescita del 20% annuo fino al 2021) è stata innescata dalla fine dei tassi di interesse a zero prima ancora dell'AI, creando oggi uno strano mix di gelo negli investimenti software tradizionali e bolla dell'AI (imprevedibile nei tempi di scoppio, ma dotata di valore reale a differenza di blockchain e crypto). Nel lungo periodo l'AI non cancellerà gli sviluppatori: la competenza chiave non è scrivere codice ma capire cosa scrivere, ossia comunicare con gli utenti (come quando modellava i processi sanitari: capiva il dominio, ma nessuno si sarebbe mai fatto curare da lui anziché da un medico). ¹

Raccomandazioni personali

• Linguaggi di programmazione: il preferito oggi è Ruby per la lunga familiarità, ma il suo vero amore resta Smalltalk (di cui cita la vitalità del progetto Pharo). ¹
• Libri: Thinking, Fast and Slow di Daniel Kahneman (per sviluppare intuizione statistica e probabilistica — abilità che Fowler allena anche con i giochi da tavolo — e riconoscere le fallacie cognitive) e The Power Broker su Robert Moses (il funzionario non eletto più potente di New York tra gli anni '20 e '60, 1.200 pagine magistrali per stile di scrittura e per capire come funziona il potere nelle democrazie), insieme alla successiva biografia in cinque volumi (quattro pubblicati finora) dello stesso autore su Lyndon Baines Johnson (LBJ). ¹
• Gioco da tavolo: Concordia, astratto ma accessibile e ricco di decisioni profonde. ¹

Vedi anche: Kent Beck, Non Determinismo del Software, Refactoring nell'Era AI, Slice Sottili e Ciclo di Feedback, Technology Radar, Spec-Driven Development e Dark Factory Agentica, Leading Words e Fondamentali del Software

Fonti e Riferimenti