Architettura per chi non può permettersi due squadre
C’è una frase che ogni sviluppatore ha pronunciato almeno una volta, di solito con la voce di chi vorrebbe già essere altrove: «il bug potrebbe essere nel modulo di import».
Potrebbe. Tre giorni dopo era da un’altra parte.
Quella frase non costa un bug, ma la ricerca del bug, che è tempo di sviluppo bruciato per tornare esattamente al punto di partenza. E il punto di partenza, per una startup, è l’unico posto in cui non ci si può permettere di tornare.
Il software non è mai fermo
Chi non fa questo mestiere immagina il software come un oggetto: lo compri, ce l’hai, è finito. Chi lo fa sa che esistono sempre almeno due versioni contemporaneamente, quella in produzione, ovvero quella che i clienti stanno usando e l’altra. Quella in sviluppo che concentra il maggior investimento e che dovrà diventare produzione in un mese.
Quando il sistema si fa complesso, quelle due versioni smettono di essere due rami e diventano due squadre, una presidia il passato: tiene in piedi ciò che già funziona, ripara bug senza rompere niente e l’altra, il futuro.
È un’organizzazione sensata… e spesso costo quasi il doppio.
In una startup quelle due squadre sono le stesse persone che devono consegnare il mese prossimo, scrivendo le funzioni nuove e che rispondono quando qualcosa si rompe in produzione (e che, in mezzo, dovrebbe anche dormire). Non hanno una riserva di giorni da bruciare ma i giorni che il conto in banca concede.
Da qui nasce una conclusione che a me pare poco discutibile: se non puoi comprare il tempo, devi progettarlo.
Cosa cambia davvero dall’MVP all’applicazione
Il passaggio da MVP ad applicazione vera viene raccontato quasi sempre come una questione di funzioni. Ne aggiungi, ne raffini, togli le cose finte. Ma non è il punto.
Un MVP è ottimizzato per dimostrare. Deve arrivare fino alla fine della demo. Se dentro è tenuto insieme con lo spago, pazienza: nessuno guarda dentro, e in quel momento è la scelta giusta, perché il rischio da abbattere è «serve a qualcuno?», non «regge diecimila utenti?».
Un’applicazione vera deve ottimizzata per essere riparata. Ha smesso di essere una dimostrazione ed è diventata una cosa che sta in piedi mentre voi fate altro… e prima o poi si romperà (succede sempre) e in quel momento la domanda che conta non è se accadrà, ma quanto tempo vi costerà scoprire dove.
La differenza tra le due frasi è tutta lì. «Il bug potrebbe essere lì» vi manda a cercare, ma «il bug deve essere qui» vi manda a riparare. La prima costa giorni, la seconda mezz’ora e la differenza si conta contemporaneamente in tempo e in danaro.
Quattro scelte che restituiscono giorni
Non sono scelte esotiche, sono noiose, questo è il motivo per cui vengono rimandate: non aggiungono niente sullo schermo, quindi non entrano mai nella riunione in cui si decide cosa fare questa settimana.
Separare i pezzi per davvero. In Canonity il backend, il frontend e il dispatcher e il documentatore sono quattro servizi distinti, con confini dichiarati. Non è eleganza accademica, ma quando qualcosa non torna, lo spazio in cui cercare si riduce di tre quarti prima ancora di aprire un file. Un monolite non ha un dentro e un fuori, quindi ogni problema è potenzialmente ovunque, diversi micro-servizi (ma anche macro-servizi) con un confine definito hanno un errore che quando attraversa il confine diventa evidente.
Mettere per iscritto il contratto, e versionarlo. Fra due componenti che si parlano c’è sempre un accordo su chi manda cosa e cosa si aspetta indietro. La domanda è se quell’accordo esiste solo nella testa di chi lo ha scritto o esiste come documento, con un numero di versione e una consegna verificata. La differenza si manifesta un attimo dopo il guasto: se il contratto è scritto, si confronta il comportamento osservato con il contratto e la discussione dura al massimo dieci minuti. Se non lo è, si confrontano due ricordi. Che non è mai un buon criterio diagnostico.
Fermarsi dove non si sa. Un sistema può reagire a una condizione che non riconosce in due modi: si blocca, oppure tira dritto immaginando un valore ragionevole. Il secondo modo è più gentile con l’utente oggi e crudele con voi fra due settimane, perché l’errore non scompare, si sposta per riemergere lontano dalla sua causa.
Dare un nome agli esiti. Sembra burocrazia e invece è metà del lavoro diagnostico. «Non funziona» è una categoria che contiene almeno tre cose diverse: è rotto, non c’è ancora, oppure l’ambiente in cui l’avete provato non era quello giusto. Sono tre problemi con tre destinatari e tre tempi di risposta diversi, e tenerli separati fin dal momento in cui si annotano evita la mezza giornata più frustrante che esista: quella passata a riparare qualcosa che non era rotto.
La parte di cui nessuno farà uno screenshot
Nessuna di queste quattro cose si vede. Non c’è una schermata da mostrare, non c’è un titolo che le renda interessanti a chi non deve manutenerle. Un investitore vi chiederà le metriche. Un utente vi chiederà le funzioni. Nessuno dei due vi chiederà mai quanto ci mettete a trovare un bug.
Ed è esattamente lì che una startup finisce i soldi: non nel guasto, che è inevitabile e in fondo economico, ma nelle settimane spese a inseguirlo con una torcia in mano.
Il software non è mai fermo, e non lo sarà nemmeno domani. Potete affrontarlo con due squadre, se ne avete i mezzi. Oppure con una sola e un’architettura che, quando succede, invece di stringersi nelle spalle vi risponde: è qui.
