In una conversazione con Lorenzo di qualche tempo fa è venuta fuori questa domanda “Come si progetta un software che deve durare 50 anni o più?“. Quando ragioniamo su orizzonti temporali così ampi è impossibile progettare nessun tipo di soluzione upfront. Questo perché la tecnologia avanza in una maniera talmente rapida e inaspettata da rendere inutile qualsiasi tipo di previsione.
Prendiamo come esempio Encarta di Microsoft, la famosa Enciclopedia digitale, distribuita su CD-ROM. Nessuna scelta architetturale durante lo sviluppo avrebbe potuto “difendere” il prodotto dall’avvento di Internet e di Wikipedia. Encarta tra l’altro ha provato a intraprendere la strada dell’online con Encarta online, ma probabilmente Microsoft si è mossa troppo tardi. Wikipedia aveva il 96,69% del traffico della categoria, contro l’appena 1,27% di Encarta.
Quindi come possiamo approcciare un progetto che ha realmente esigenze di business tali che ci portano a ragionare su un tempo così lungo? Siamo soli in balia degli eventi? Secondo me no, qualcosa si può fare.
C’è una cosa che sicuramente il nostro progetto dovrà affrontare in questi 50 anni – ed è qualcosa che possiamo imparare a gestire – il Cambiamento. Dobbiamo quindi cambiare paradigma, la domanda da farci non è più “Come si progetta un software che deve durare 50 anni o più?” ma “Come possiamo progettare un software resiliente al cambiamento per 50 anni?“
Sappiamo inoltre che il cambiamento sarà costante e potenzialmente distruttivo per il nostro business. Il cambiamento è ben rappresentato secondo me da delle onde, sono costanti e di varia entità. E proprio questa metafora ci fa capire che essere resilienti non basta. È come fermare delle onde con un muro. Può funzionare per molti anni, ma se arriva un’onda anomala a quel punto il muro crolla. Cosa intendo con onda anomala? Pensate al caso Blockbuster.
L’ascesa dei servizi di streaming ha reso tutto l’impero di Blockbuster obsoleto in una manciata di anni. Questo tipo di “onda” quando arrivano non si possono fermare, vanno cavalcate. Non dobbiamo essere solo resilienti al cambiamento. Dobbiamo tendere a essere antifragili e trasformare ogni cambiamento da un problema ad una nuova opportunità di business. ?
Abbiamo teorizzato e messo in pratica un nuovo format pensato per testare l’antifragilità di una base di codice. Questo format si chiama Architectural Clash.
Durante un Architectural Clash si tenta di risolvere un problema molto impegnativo, legato ad una base di codice esistente, in un tempo molto breve. L’obiettivo è imparare quanto più in fretta possibile quali sono i limiti del nostro attuale software e migliorare il suo grado di antifragilità e non risolvere il problema in sé. Un Architectural Clash ha una durata che va da una a due giornate ed è suddiviso in tre fasi.
Fase 0: la scelta dell’obiettivo
Lo scopo della prima fase è quella della selezione dell’obiettivo che il team cercherà di raggiungere durante il Clash. Potete utilizzare un metodo di brainstorming qualsiasi, da un Fishbowl a Lego Serious Play. L’importante è ricordare che l’obiettivo deve essere condiviso da tutta l’azienda. È quindi fondamentale portare in questo tavolo anche dei rappresentanti dell’area business per tenere a mente il loro punto di vista. Una volta individuato l’obiettivo lo si scrive su un grosso post-it. Inoltre si scrive sul retro del post-it il perché quell’obiettivo è importante. Tutte le decisioni che si prenderanno durante il corso del Clash dovranno tener conto di questo “perché” condiviso. Alcuni esempi di obiettivi sono “Riscrivere la nostra applicazione AngularJS in un altro framework – Per migliorarne la manutenibilità” oppure “Cambiare il nostro piano di sottoscrizione da mensile ad uno pay-per-use – Perché vogliamo testare un nuovo modello di Business”. Ricordate che l’obiettivo non sarà raggiunto durante il clash, l’obiettivo è imparare quanto più possibile dalla base di codice con la quale lavoriamo. Il principio da tenere a mente durante questa prima fase è “Start with why”. Il team deve iniziare subito con il calibrarsi su un “perché” prima ancora di un “cosa”. In questo modo il risultato sarà sicuramente migliore in quanto sentito e condiviso da tutti.
Fase 1: Il Clash
Una volta selezionato l’obiettivo è il momento di mettersi all’opera, dividete il vostro team in piccoli gruppi e lavorate per sprint di 1 o 2 ore. Inizia in pratica la fase di Clash. Alla fine di ogni sprint i team si incontrano nella stessa stanza e si scambiano informazioni su come stanno tentando di raggiungere l’obiettivo e i loro risultati. Un aspetto importante è che i team non sono sigillati ma anzi è importante che si mescolino e che le persone siano libere di andare dove sentono di poter portare un contributo. Il processo è molto simile ad un CodeRetreat e non è un caso: il principio alla base è lo stesso, Learning-by-doing.
Citando Alberto Brandolini…
Software development is a learning process, working code is a side effect. If that’s true… how can we maximize learning?
Per aumentare il grado di “learning” che vogliamo ottenere lavoriamo su continui esperimenti timeboxati, codice alla mano. In questo modo il nostro grado di conoscenza della base di codice (e quindi delle sue problematiche) aumenta in maniera esponenziale. Questo perché ci forziamo a risolvere problemi reali, in maniera iterativa, anche se in una sandbox protetta.
Fase 2: Conclusioni
Le ultime due ore del format servono per trarre le conclusioni. Ora lo scopo di tutto il team è quello di creare un piano di azione per incrementare il grado di antifragilità del software. Ognuno dei presenti esporrà i propri risultati concentrandosi sui roadblock che non hanno permesso al codice di adattarsi velocemente alle nuove specifiche: è lì che bisogna intervenire.
In questa fase è fondamentale ragionare in ottica Kaizen, piccoli miglioramenti continui. Il motivo di questo approccio è semplice: noi sviluppattori tendiamo a odiare il codice scritto poco tempo prima e a voler riscrivere tutto da zero. Ma questa cosa è difficilmente compatibile gli obiettivi di business, quindi bisogna mettere in campo dei piccoli refactor che gradualmente migliorano la qualità del nostro software. In questa fase non è importante puntare verso l’obiettivo scelto, perché quello che vogliamo ottenere è un aumento dell’antifragilità in generale del nostro software, ma è importante tenere in mente il “perché” che è scritto sul retro del vostro post-it. Prendiamo ad esempio l’obiettivo “Riscrivere la nostra applicazione AngularJS in un altro framework – Per migliorarne la manutenibilità“. In questo il cambio di framework era solo un pretesto per imparare. Le azioni che decidiamo di mettere in campo devono andare verso la manutenibilità, ma nel disegnare il piano tieniamo conto delle difficoltà incontrare durante il Clash. Proprio un Architectural Clash ci ha portato verso la svolta Frameworkless di uno dei nostri progetti storici.
Side Effects
Oltre agli effetti positivi che avevamo definito by design discussi nel post, ci siamo accorti che questo format genera un forte allineamento nel team e in generale una sensazione di entusiasmo per quello che verrà. In generale credo che uno sviluppatore felice sia uno sviluppatore migliore, quindi questo side effect stata una gradita sorpresa. La cosa è particolarmente impressionante se provate su progetti legacy che la gente tende ad odiare. Quello che consigliamo quindi è far diventare questo format un vero e proprio rito per i progetti più importanti, in maniera del tutto analoga ad una retrospettiva.
Wanna Try?
Abbiamo distillato le informazioni sul format in un manifesto che potete leggere sul sito architecturalclash.org. Nulla è scolpito nella pietra, anzi vogliamo il confronto con tutti gli interessati. Se lo provate nelle vostre organizzazioni e volete lasciare feedback oppure se volete provare a prepararne uno e volete un nostro parere non esitate a contattarci. Inoltre anche quest’anno sono stato speaker all’Agile Day, che quest’anno si è tenuto Urbino, proprio con un talk sull’Architectural Clash.
Photo Credits: chris m. on Flickr
