Edo, l’antica Tokyo: come l’acqua e il fuoco ci insegnano a costruire software resiliente

Abstract

Attraverso la visione del documentario “Alle origini di Tokyo”, il team ha esplorato come la storia di Edo, l’antica Tokyo, offra preziose lezioni per progettare architetture software resilienti. Due forze, l’acqua e il fuoco, hanno plasmato la città e ispirato riflessioni su adattabilità, semplicità, gestione del cambiamento e spirito di comunità. Il percorso, articolato in due incontri, ha evidenziato l’importanza di creare sistemi vivi e modulari, capaci di evolversi senza rompersi, dove il vero valore non risiede solo nella tecnologia, ma nel mindset e nella collaborazione tra le persone. Attraverso Edo, il team ha riscoperto principi fondamentali per costruire software flessibile, robusto e capace di prosperare nel cambiamento.


Cosa c’entra la storia di Tokyo con le architetture software? Apparentemente nulla, ma in questo articolo voglio raccontare il percorso che abbiamo intrapreso con il Team per rispondere a questa domanda, partendo dalla visione del documentario “Alle origini di Tokyo” e arrivando a riflessioni preziose per il nostro lavoro quotidiano.

L’ispirazione

Poco più di un anno fa, in un momento di confronto con Nicola Bonicelli, Software Architect in Facile.it, discutevamo di architetture software e, in particolare, della ricerca di un equilibrio tra semplicità e capacità di adattamento al cambiamento.

Nicola, appassionato sia di software che di cultura orientale, mi ha suggerito di guardare due puntate del programma “a.C.d.C.” su Rai Play, intitolate “Alle origini di Tokyo”. Da subito ho riconosciuto il volto di Alessandro Barbero e ho capito che avrei assistito non solo a un documentario affascinante, ma anche a un contenuto di qualità. Purtroppo, ad oggi, entrambe le puntate non risultano più disponibili su RaiPlay.

Dopo aver visto le puntate, il confronto con Nicola si è approfondito: ci siamo trovati a riflettere su come la crescita di Edo (l’antica Tokyo) potesse essere un modello sorprendentemente efficace per pensare a sistemi software resilienti e adattivi.

Abbiamo deciso di coinvolgere uno dei miei Team in questo viaggio: due meeting prima della pausa estiva, ciascuno dedicato alla visione di una delle due puntate, seguita da una discussione libera.

Due puntate, due elementi: acqua e fuoco

Le due puntate si concentrano su due forze naturali opposte che hanno modellato Edo: l’acqua e il fuoco. L’acqua, fonte di vita e sviluppo commerciale, è stata sfruttata con intelligenza attraverso un sistema di canali che fungeva sia da difesa che da arteria commerciale. Il fuoco, invece, elemento distruttivo, ha costretto Edo a sviluppare strategie di resilienza e rigenerazione continua, trasformando ogni grande incendio in un’opportunità di crescita.

Figura 1 – Un momento della proiezione di “a.C.d.C.”

Le riflessioni del Team

Primo meeting (21 luglio 2023): Edo, città dell’acqua

Dal primo incontro sono emersi due filoni principali di riflessione: il mindset e le scelte di design.

Sul fronte del mindset, abbiamo osservato come la cultura di Edo mostrasse una straordinaria capacità di vivere il cambiamento in modo collettivo. L’approccio era quello di accogliere il cambiamento come parte naturale della vita, adattandosi insieme agli altri, piuttosto che ostinarsi a mantenere lo status quo. Questa mentalità, molto diversa da quella europea che celebra il genio individuale, si basa invece sull’intelligenza collettiva e sulla forza della comunità.

Per quanto riguarda le scelte di design, il sistema dei fossati di Edo rappresenta una metafora potente. A differenza delle mura europee, che difendevano ma anche limitavano la crescita delle città, i fossati di Edo erano flessibili e ampliabili. Questa caratteristica è stata collegata al concetto di architettura software: progettare sistemi troppo rigidi – come i monoliti – può ostacolare l’evoluzione. Meglio, invece, costruire architetture modulari – come i microservizi – capaci di espandersi e adattarsi nel tempo.

Figura 2 – Monolite Vs Microservizi

Una lezione chiave che abbiamo tratto è l’importanza di “sapere cosa è sufficiente”: un principio che guida scelte pragmatiche e che permette di evitare soluzioni eccessivamente complesse o sovra-ingegnerizzate.

Secondo meeting (28 luglio 2023): Edo, città del fuoco

Il secondo incontro ha arricchito ulteriormente le nostre riflessioni.

Abbiamo compreso che sbagliare fa parte naturale del processo evolutivo. Gli abitanti di Edo non si sono mai demoralizzati di fronte agli incendi devastanti, ma hanno saputo apprendere dai propri errori e migliorare continuamente. Questo atteggiamento ci ha fatto riflettere su quanto sia importante, anche nel nostro lavoro, accettare l’errore come occasione di crescita e non come fallimento. Riconoscerlo non significa attribuire colpe, ma aprire la strada alla correzione e all’apprendimento. Perché ciò avvenga, serve un ambiente che incoraggi la condivisione degli errori e faccia sentire le persone libere di parlarne senza timore. Oggi parliamo di psychological safety.

Un altro aspetto emerso è la gestione del transitorio. Il fuoco, in fondo, rappresenta il cambiamento: un evento che mette in discussione lo status quo ma apre anche la possibilità di rinnovamento. I giapponesi erano in grado di ricostruire parti della città mentre la vita quotidiana continuava. Nel nostro mondo, questo si traduce nella capacità di effettuare refactoring senza bloccare il funzionamento dei sistemi: un parallelismo diretto con le pratiche moderne di software engineering, dove il cambiamento avviene “a caldo”, senza fermare la produzione.

La mentalità pragmatica e comunitaria di Edo si è dimostrata ancora una volta centrale. L’obiettivo principale non era proteggere ogni singolo edificio, ma salvare le persone e preservare la vitalità della città. È un parallelismo significativo con il modo in cui dovremmo pensare alle soluzioni software: ciò che conta è il beneficio per il sistema nel suo insieme, non per i singoli componenti. In entrambi i casi, non esistono scelte “giuste” in senso assoluto, ma scelte “adatte” al contesto e alle priorità del momento.

Durante la discussione è emerso anche un confronto interessante tra Edo e Londra. Dopo il grande incendio, Londra rispose con una regolamentazione stringente sull’uso di materiali non infiammabili, ma questa rigidità contribuì a rallentare la crescita demografica e urbana. Edo, invece, puntò su soluzioni flessibili e comunitarie, che permisero una ripresa più rapida ed efficace.

Abbiamo riflettuto sul valore della semplicità: costruzioni leggere, materiali economici, capacità di ricostruire in pochi giorni. Questa semplicità operativa, applicata anche al mondo software, suggerisce di evitare soluzioni troppo complesse che possono ostacolare la manutenzione e l’evoluzione.

La preparazione e l’osservabilità sono risultate condizioni fondamentali. Gli abitanti di Edo erano pronti a reagire agli incendi perché sapevano cosa fare. Allo stesso modo, nei sistemi software, la capacità di osservare in tempo reale e di sapere dove intervenire rapidamente fa la differenza tra una crisi gestibile e un disastro.

Una delle intuizioni più potenti emerse dai meeting è che “ciò che fa davvero la differenza non si vede”: sono le persone, la mentalità, la capacità di collaborazione. Non basta la tecnologia più avanzata: è il modo in cui viene usata, è il mindset condiviso a determinare il successo. Gli abitanti di Edo affrontavano gli incendi quasi col sorriso: sapevano di essere preparati e, soprattutto, di poter contare gli uni sugli altri per ricostruire. Questa fiducia collettiva ci invita a riflettere su quanto sia importante, anche nel lavoro, creare le condizioni per affrontare serenamente le difficoltà e rendere ogni iterazione davvero sostenibile.

Abbiamo anche toccato concetti più tecnici, come il teorema CAP: nei sistemi distribuiti, non è possibile ottenere contemporaneamente consistenza immediata, disponibilità continua e tolleranza alle partizioni. Edo ci insegna che a volte è meglio accettare piccoli compromessi locali – ad esempio una consistenza eventuale – pur di garantire la resilienza e la disponibilità del sistema complessivo.

Infine, il tema della velocità di reazione ha trovato una potente analogia nei racconti moderni: ad esempio, la capacità di ricollegare due linee ferroviarie a Tokyo in sole tre ore, grazie a una preparazione minuziosa e a una collaborazione perfetta tra migliaia di persone.

Lezioni per il nostro lavoro

Il percorso attraverso la storia di Edo ci ha lasciato insegnamenti profondi:

  • L’adattamento è centrale: è necessario progettare con la consapevolezza che il cambiamento è inevitabile e fa parte della natura stessa dei sistemi software.
  • Il senso di comunità è un moltiplicatore di valore: costruire team che collaborano davvero è più importante di qualsiasi tecnologia.
  • Le soluzioni devono essere “sufficienti”, non necessariamente perfette: cercare sempre un equilibrio tra qualità e semplicità.
  • Occorre evitare barriere rigide: progettare architetture capaci di evolvere nel tempo.
  • E’ fondamentale privilegiare il refactoring continuo e l’approccio iterativo rispetto a strategie “big bang”.
  • L’observability è cruciale: sapere cosa sta succedendo è fondamentale per reagire in tempo.
  • La resilienza è una condizione imprescindibile: costruire sistemi capaci di sacrificare parti senza compromettere l’intero è una filosofia vincente.

Conclusioni

Guardando a Edo e alla sua storia, abbiamo ritrovato un’immagine potente del modo in cui possiamo e dobbiamo pensare le nostre architetture e il nostro lavoro: come sistemi vivi, flessibili, pronti a cambiare senza perdere il sorriso.

Ringrazio Nicola per avere ideato insieme questo momento e tutto il Team per l’entusiasmo, la profondità delle riflessioni e la partecipazione. Non è stato solo un esercizio culturale: è stato un autentico momento di crescita professionale e personale.

Published by

Salvatore Cordiano

Empathetic Rebel Engineer

Leave a Reply

Your email address will not be published. Required fields are marked *