Ciao, e benvenuto nella seconda puntata della settantatreesima stagione. Nella prima abbiamo detto che DevOps è, prima di tutto, la scelta di abbattere il muro tra chi costruisce e chi manda in produzione. Oggi prendo quel principio e lo condenso nella frase più importante e più fraintesa di tutta questa disciplina, la frase da cui discende ogni cosa: costruiscilo, e fallo funzionare. Chi crea una cosa è anche chi la tiene in vita.
Partiamo da cosa significa, in pratica, perché suona semplice ma cambia tutto. Nel vecchio mondo, lo sviluppatore scriveva il codice, lo passava oltre il muro, e la sua giornata finiva lì. Se alle tre di notte quel codice andava in crisi, a svegliarsi era qualcun altro, che quel codice non l'aveva scritto e faticava a capirlo. Costruiscilo e fallo funzionare rovescia la scena: chi ha scritto quel codice è anche chi riceve la chiamata nel cuore della notte, chi lo vede vivere in produzione e ne paga i disastri. La responsabilità non si passa più oltre il muro: resta attaccata a chi ha creato la cosa.
Vediamo perché questa idea, che a prima vista sembra solo più faticosa, è in realtà geniale: chiude il giro del ritorno. Quando chi costruisce non vede mai cosa succede in produzione, non impara niente dai propri errori: continua a scrivere codice difficile da tenere in piedi, tanto il dolore lo sente qualcun altro. Ma quando è lui a essere svegliato alle tre di notte dal proprio codice, la volta dopo lo scriverà in modo diverso: più robusto, più facile da capire quando qualcosa va storto, con dentro già i segnali per diagnosticarlo. Il dolore, tornando al mittente, diventa il miglior maestro possibile.
Nota come questo allinea di colpo gli interessi di tutti, sciogliendo il conflitto di partenza. Ricordi le due tribù con obiettivi opposti, una che voleva cambiare e una che voleva stabilità? Quel conflitto nasceva dal fatto che il costo del cambiamento lo pagava qualcun altro. Nel momento in cui chi cambia è anche chi paga se il cambiamento rompe qualcosa, la tensione tra velocità e stabilità smette di essere una guerra tra reparti e diventa una decisione sensata dentro la stessa testa. Vado veloce, sì, ma con giudizio, perché se combino un guaio la sveglia suona per me. Non serve più un muro a fare da arbitro: l'arbitro è la responsabilità condivisa.
Torniamo alla nostra fabbrica, perché l'immagine lo rende ovvio. Immagina un artigiano che costruisce una sedia e la vede uscire dal negozio con il cliente. Se quella sedia si rompe dopo una settimana, è lui a vedere tornare il cliente arrabbiato, è lui a doverla riparare. Quell'artigiano imparerà in fretta a costruire sedie solide, perché il ritorno del suo lavoro gli arriva dritto in faccia. Ora immagina invece una catena dove uno taglia il legno, un altro lo incolla, un terzo lo vende, e nessuno vede mai la sedia rotta tornare indietro: quella catena può produrre sedie scadenti all'infinito, e nessuno saprà mai perché i clienti non tornano. Vedere le conseguenze del proprio lavoro è ciò che ci rende capaci di migliorarlo.
E qui va detta una cosa onesta, perché questa idea ha un lato umano delicato che non va idealizzato. Far possedere alle persone ciò che costruiscono è potente, ma se fatto male diventa solo un modo per scaricare su chi sviluppa anche il peso di essere reperibile giorno e notte, senza dargli gli strumenti, il tempo o il supporto per gestirlo. Costruiscilo e fallo funzionare funziona solo se chi costruisce ha anche il potere di renderlo affidabile, il tempo per curarlo, e una squadra che condivide il carico invece di lasciarlo solo. La responsabilità senza il potere di agire non è ownership: è solo colpa che aspetta di cadere su qualcuno. Il rispetto per le persone, di cui parlavamo tempo fa, resta la condizione perché tutto questo sia sano.
Voglio lasciarti con il senso profondo di questo principio, perché va oltre la tecnica. Costruiscilo e fallo funzionare non è una punizione per gli sviluppatori: è la restituzione di una cosa preziosa, il contatto con la realtà del proprio lavoro. È la differenza tra scrivere codice come chi lancia lettere in un pozzo senza sapere se arrivano, e scrivere codice come chi accompagna la propria creatura nel mondo e se ne prende cura. Tutti gli strumenti di DevOps di cui parleremo esistono per rendere questa cura sostenibile. Ma la cura, la scelta di possedere ciò che crei dall'inizio alla fine, viene prima di ogni strumento.
Per oggi ci fermiamo qui. Abbiamo condensato DevOps nella sua frase più importante: costruiscilo, e fallo funzionare. Chi scrive il codice è anche chi riceve la chiamata di notte, chi lo vede vivere e ne paga i disastri: la responsabilità resta attaccata a chi crea, invece di scavalcare il muro. Questo chiude il giro del ritorno, perché il dolore che torna al mittente insegna a costruire meglio, e allinea gli interessi, perché chi cambia è anche chi paga, e la guerra tra velocità e stabilità diventa una scelta sensata nella stessa testa. Come l'artigiano che vede tornare la sedia rotta. Ma vale solo se alla responsabilità si dà anche il potere, il tempo e il supporto per agire, altrimenti è solo colpa che cade su qualcuno. Nella prossima puntata: il flusso del lavoro. Nelle note trovi qualche spunto. Se ti è utile, condividila. Grazie per l'ascolto, e ci sentiamo alla prossima.