💼 4 lezioni rivoluzionarie da “Software Engineering at Google” 🔗

Il celebre articolo pubblico del 2017 di Fergus Henderson, Software Engineering at Google (arXiv:1702.01715), offre uno sguardo affascinante sulla cultura ingegneristica, sugli strumenti e sui processi che alimentano lo sviluppo software su larga scala.

Quando si legge di ingegneria su scala enterprise, è facile cadere nella trappola di pensare: “La mia azienda non è così grande, quindi questo non vale per noi”. Tuttavia, il vero valore dell’articolo di Henderson non risiede negli specifici strumenti proprietari citati, ma nella filosofia di fondo su come gestire la complessità, scalare i team e mantenere la salute del codice nel tempo.

Invece di cercare di copiare la loro esatta configurazione, ecco quattro insegnamenti di alto livello tratti dall’articolo da cui i team di ingegneria di qualsiasi dimensione possono imparare e che possono adattare alla propria realtà.

📑 Indice 🔗

🤖 1. L’automazione implacabile è il fondamento della scalabilità 🔗

Uno degli aspetti più sorprendenti dell’articolo è l’enorme volume di automazione necessario per mantenere in movimento lo sviluppo. Dai sistemi di build distribuiti ai test automatizzati eseguiti su ogni singola modifica delle dipendenze, l’intervento manuale è ridotto al minimo ovunque sia possibile.

La lezione: Non serve un sistema di build cloud personalizzato per abbracciare questa mentalità. L’obiettivo è rimuovere l’attrito dall’esperienza dello sviluppatore. Se il tuo team esegue ancora manualmente gli script di deployment o si affida alla “speranza” che un commit non rompa il branch principale, è il momento di investire seriamente in pipeline CI/CD, controlli pre-submit e build deterministiche. Fai in modo che il “modo giusto” di fare le cose sia anche il più semplice e automatizzato.

🤝 2. La qualità del codice è una cultura collaborativa, non un’imposizione 🔗

Henderson delinea un ambiente rigoroso in cui ogni riga di codice richiede una revisione e le guide di stile dettano la coerenza tra i vari linguaggi. Eppure, tutto ciò non viene presentato come una tattica manageriale draconiana, bensì come una rete di sicurezza collaborativa. Inoltre, un repository unificato consente a chiunque di correggere il codice difettoso ovunque si trovi, a patto di sapere come fare.

La lezione: Le code review non dovrebbero essere un collo di bottiglia o una gara di ego; sono il meccanismo principale per condividere la conoscenza e mantenere una codebase unificata. L’applicazione di guide di stile rigorose (magari tramite linter automatizzati) elimina le discussioni banali nelle pull request, consentendo agli sviluppatori di concentrarsi sulle revisioni architetturali e logiche. Promuovi una cultura in cui gli sviluppatori si sentano autorizzati a risolvere problemi anche al di fuori dei confini immediati del proprio progetto.

🛡️ 3. Sicurezza psicologica e cultura “Blameless” (senza colpevolizzazione) 🔗

Quando le cose vanno storte — e inevitabilmente succede — la risposta è altamente strutturata ma del tutto priva di colpevolizzazioni (blameless). I post-mortem sono obbligatori per i disservizi significativi e si concentrano rigorosamente sulle tempistiche, sulle cause profonde e sulle strategie di prevenzione attuabili, anziché puntare il dito contro i singoli individui.

Inoltre, l’articolo tocca la realtà delle “riscritture frequenti”. Esiste una consapevolezza istituzionale del fatto che il codice scritto qualche anno fa è stato progettato per un insieme diverso di requisiti e che naturalmente finirà per degradarsi o diventare obsoleto.

La lezione: Gli errori sono sistemici, non personali. Se un ingegnere manda in blocco la produzione, la domanda non dovrebbe essere “Perché l’hai fatto?”, ma piuttosto “Perché i nostri sistemi ti hanno permesso di farlo?”. Adottare post-mortem senza colpevolizzazione crea sicurezza psicologica, incoraggiando gli ingegneri ad assumersi rischi calcolati e ad ammettere tempestivamente gli errori. Allo stesso modo, i team devono accettare che il software è un organismo vivente: il refactoring e la riscrittura non dovrebbero essere visti come un fallimento del progetto originale, ma come una parte naturale del ciclo di vita del software.

⚖️ 4. Bilanciare allineamento e autonomia 🔗

L’articolo mette in luce un’affascinante dualità nella gestione dei progetti e delle persone. Da un lato, c’è un rigoroso allineamento aziendale attraverso gli Objectives and Key Results (OKR), che assicurano che tutti spingano verso obiettivi aziendali misurabili. Dall’altro, esistono meccanismi di estrema autonomia, il più famoso dei quali è la politica del “20% del tempo”, che consente agli ingegneri di esplorare progetti a propria scelta.

La lezione: L’innovazione prospera quando gli ingegneri comprendono gli obiettivi generali ma ricevono la fiducia e lo spazio necessari per risolvere i problemi in modo creativo. Anche se non tutte le startup possono permettersi di lasciare libero un quinto del tempo dei propri sviluppatori, è comunque possibile promuovere l’autonomia. Fornisci obiettivi chiari e misurabili (il “cosa” e il “perché”) e fai un passo indietro per lasciare che il tuo team di ingegneria determini la migliore esecuzione tecnica (il “come”).

🎯 Conclusioni 🔗

L’articolo di Fergus Henderson ci ricorda che scrivere codice è solo una piccola frazione dell’“ingegneria del software”. La vera ingegneria riguarda gli strumenti, la cultura e i processi che permettono al codice di vivere, adattarsi e scalare nel tempo. Concentrandosi sull’automazione, su una cultura senza colpevolizzazione e sulla qualità collaborativa del codice, qualsiasi team può costruire un ambiente ingegneristico più sano.