In un mondo dominato dalla velocità di sviluppo e dall’innovazione continua, il fallimento non è sempre una battuta d’arresto—anzi, può rivelarsi una strategia vincente.
Parliamo di Fail Fast, una metodologia fondamentale in ambito software, che mira a identificare rapidamente limiti e criticità di una soluzione.
Che cos’è il Fail Fast?
Il Fail Fast è un modus operandi con un solo obiettivo: trovare un potenziale punto di arresto. Se Cartesio diceva Cogito ergo sum, qui potremmo dire Deficio ergo sum (fallisco, quindi esisto).
Questo approccio è particolarmente cruciale in contesti come l’IoT (Internet of Things), dove le variabili sono numerose e spesso fuori dal nostro controllo diretto. Ma, fidatevi, questa metodologia può rivelarsi utile in qualsiasi ambito.
Immaginate di lavorare con una “scatola nera”, un elemento su cui non abbiamo piena visibilità o influenza. La documentazione è sommaria, con una lista dei behaviour previsti, ma poche certezze. Dall’altro lato, però, ci sono user stories dettagliate, riviste insieme ai team di UX e QA, pronte per essere messe alla prova con test plan rigorosi.
Allora perché puntare a fallire?
Perché scoprire prima possibile che qualcosa non funziona ci permette di prendere decisioni tempestive, aggiustare il tiro e, se necessario, attivare delle escalation.
Il Fail Fast è l’antitesi del “sandbagging”, ovvero dell’abitudine di procrastinare un problema nella speranza che venga dimenticato o catalogato come “non riproducibile”.
Agendo subito, possiamo evitare che i problemi si accumulino e diventino ingestibili.
Come metterlo in pratica?
Il Fail Fast trova spesso applicazione attraverso i Proof of Concept (PoC).
Un team, o anche un singolo sviluppatore, testa una soluzione per validarla rapidamente. Ma non ci si limita a una semplice verifica di funzionamento: il PoC deve sfidare la soluzione, metterla alla prova in condizioni che potrebbero causarne il fallimento.
Di solito, in queste attività si coinvolgono figure Senior o Expert, grazie alla loro esperienza nel riconoscere punti critici e “colpire” dove è più probabile trovare problemi. Tuttavia, non è un requisito assoluto: chiunque, con la giusta mentalità e approccio, può contribuire al processo di Fail Fast.
Un esempio pratico: la sincronizzazione BLE in background su iOS
Un contesto dove è facile applicare questa strategia è quello dell’hardware, spesso caratterizzato da “black box” su cui abbiamo un controllo limitato.
Molti di voi avranno una smart band o uno smart ring. Questi dispositivi raccolgono dati in modo continuo e, per voi utenti, è comodo aprire l’applicazione e trovare i dati aggiornati senza dover attendere un lungo processo di sincronizzazione, giusto?
Perfetto, ma se consideriamo tra le criticità l’utilizzo del BLE (Bluetooth Low Energy) e iOS in background, ci troviamo di fronte a una potenziale polveriera pronta a esplodere in un attimo.
Per esperienza, sappiamo che ci sono pattern critici che coinvolgono BLE e iOS in diversi frangenti (ci sarebbe da parlarne per giorni…), ma un esempio classico di applicazione del Fail Fast è verificare immediatamente se il peripheral non richiede, banalmente, un’interazione fisica per mantenere o ristabilire la connessione.
Se non facciamo questo test subito, rischiamo di scoprire troppo tardi che le sincronizzazioni in background non funzionano come previsto. E questo potrebbe significare la fine dell’esperienza di utilizzo fluida che l’utente si aspetta, costringendo a rivedere l’intero progetto software o hardware.
O a vedere crescere e crescere le cattive review sugli store.
Fail Fast: dal PxD (Physical x Digital) al D² (Digital x Digital)
Nel contesto Physical x Digital (PxD), come spesso accade nei progetti IoT, il Fail Fast è quasi obbligatorio. Ma vale la pena applicarlo anche nel Digital x Digital (D²), ovvero in progetti puramente digitali. Se riceviamo una documentazione di una API REST o GraphQL, per esempio, perché non testarla subito in uno scenario reale, dove potrebbe fallire? Meglio scoprirlo noi, che il nostro cliente.
“Ma ci sono già i test automatici, no?”
Vero, molti pensano che una soluzione validata da unit test e QA interna sia sicura. Tuttavia, recenti fallimenti, persino in ambiti come l’aerospace, dimostrano che anche un sistema apparentemente stabile può riservare sorprese quando una entità terza inizia ad interagirci. Testare con un approccio Fail Fast, magari con una time-box precisa, potrebbe fare la differenza.
Sono curioso di sapere cosa ne pensate e se adottate questa pratica anche voi. Avete esempi concreti? Fatemi sapere!
