La differenza tra uscire alle sei e ordinare pizza a mezzanotte

Esiste un test infallibile per distinguere un progetto software gestito da professionisti da uno gestito da incompetenti. Non serve analizzare l’architettura, non serve esaminare il codice, non serve nemmeno guardare la documentazione. Basta osservare cosa succede il giorno del rilascio in produzione. I professionisti escono dall’ufficio quando fuori è ancora giorno, magari si fermano per una birra celebrativa. Gli altri ordinano pizza in ufficio a mezzanotte, ancora incerti se il sistema sopravviverà fino all’alba.

L’anatomia di un disastro prevedibile

Il rilascio in produzione è il momento della verità. Tutto quello che hai costruito, debuggato, testato e modificato nei mesi precedenti viene finalmente esposto agli utenti reali. È come premere il pulsante rosso di una valigetta presidenziale: da quel momento, persone vere iniziano a interagire con il tuo sistema. Il numero può variare da zero (progetti inutili che nessuno userà mai) fino a cifre esorbitanti.

I primi minuti post-rilascio sono sempre intensi. Il team si trasforma in un branco di suricati ansiosi, tutti con gli occhi fissi sui monitor, scrutando ossessivamente ogni movimento nei log di sistema. “Si stanno loggando?”, “Guardiamo i log!”, “Ma questo utente cosa sta cercando di fare?”. Il tempo si dilata, i secondi diventano ore, l’adrenalina scorre a fiumi.

Ma c’è una differenza abissale tra l’ansia sana del vedere finalmente il proprio lavoro in azione e il panico puro derivante dal realizzare che tutto sta andando a rotoli. Nel primo caso, osservi con soddisfazione il sistema che scala elegantemente sotto il carico crescente, il codice che corre felice sui server. Nel secondo, assisti a uno scenario apocalittico degno dei peggiori film catastrofici.

Il punto di non ritorno

In alcuni rilasci disastrosi viene stabilita un’ora limite, un confine temporale oltre il quale tornare indietro diventa impossibile o proibitivamente costoso. Superata quella soglia, devi per forza andare avanti, qualunque cosa succeda. È come cercare di rimettere il dentifricio nel tubetto: teoricamente possibile, praticamente un’impresa titanica.

Quando ti avvicini a quell’ora critica e il responsabile del progetto continua a ripetere “teniamoci aggiornati” senza prendere una decisione, realizzi con chiarezza cristallina di aver navigato per mesi su una nave di cartone. Tutto diventa improvvisamente evidente: il manager incapace di decidere, l’architetto che ha costruito un mostro di complicazione che non scala, gli sviluppatori che hanno prodotto codice fragile.

Ti ricordi di tutti i segnali d’allarme ignorati. Quella volta che l’architetto aveva risposto “è troppo complicato da spiegare” quando gli chiedevi perché avesse scelto quella soluzione. Quando il lead developer aveva liquidato le preoccupazioni sulla scalabilità con un “ci penseremo quando sarà il momento”. Quel momento è arrivato, e nessuno sa cosa fare.

È in questi momenti che capisci il vero significato dell’espressione “lavorare con un cumulo di incompetenti”. È come trovarsi in un ristorante dove il cuoco è convinto di essere un genio incompreso mentre serve piatti che violano ogni legge della gastronomia. Solo che invece di cibo immangiabile, qui si parla di sistemi che crollano sotto i propri utenti.

Il paradosso del buon senso

Paradossalmente, far andare le cose lisce è relativamente facile se ti muovi con buon senso. Il problema è che il buon senso è la risorsa più rara nel mondo IT. È come se entrando in questo settore venisse impiantato un chip che sostituisce la logica elementare con una perversa attrazione per le soluzioni più controproducenti possibili.

Esiste una legge non scritta secondo cui se qualcosa può essere fatto in modo semplice ed efficace, deve assolutamente essere implementata nel modo più barocco e fragile immaginabile. La complessità fine a se stessa diventa un distintivo d’onore, quando in realtà è solo il sintomo di progettazione scadente.

Un rilascio in produzione ben pianificato dovrebbe essere noioso. Sì, proprio così: N-O-I-O-S-O. Dovrebbe essere un processo così ben oliato e automatizzato che l’unica vera emozione è vedere gli utenti interagire positivamente col tuo lavoro. Se durante un rilascio sudi freddo, preghi divinità che non credevi di conoscere, o consideri seriamente un cambio di carriera, allora c’è qualcosa di profondamente sbagliato nel processo.

Come si prepara un rilascio vero

Un buon rilascio comincia mesi prima, non la sera prima del go-live. Richiede test automatizzati che coprono ogni aspetto critico del sistema. Deployment automatizzati eseguiti regolarmente in ambienti di staging il più possibile simili alla produzione. Feature flag che permettono di abilitare o disabilitare funzionalità senza dover rifare il deployment. Strategie di rollback ben definite e testate regolarmente, non teorizzate al volo durante l’emergenza.

Ma queste sono cose che chi non sa cosa sta facendo non capisce. Per loro, il rilascio è quell’evento mistico in cui si copia il codice sul server di produzione, si incrociano le dita e si spera che funzioni. È programmazione voodoo: rituali senza comprensione, speranza invece che ingegneria.

La stanza durante questi rilasci disastrosi si trasforma gradualmente in un mix tra cimitero di lattine di energy drink e manicomio. Sviluppatori che parlano da soli davanti ai monitor, DevOps che alternano preghiere a imprecazioni in lingue morte. Gli occhi iniettati di sangue dalla caffeina, il cervello annebbiato dalla stanchezza, tutti cercano disperatamente di capire perché quel maledetto componente non vuole collaborare.

Cosa significa essere bravi davvero

La domanda che sorge spontanea in queste situazioni è: sono io che penso di essere bravo, o sono davvero circondato da incapaci? La risposta, paradossalmente, può contenere entrambe le possibilità.

Essere bravi in questo settore non significa conoscere l’ultimo framework alla moda o aver memorizzato tutti i design pattern esistenti. Significa soprattutto prevedere i problemi prima che si manifestino. Progettare sistemi che possano evolvere senza crollare sotto il proprio peso. Comunicare efficacemente con il team e con i clienti. Avere l’umiltà di riconoscere che nessun sistema è perfetto, che ogni decisione comporta compromessi.

A volte la soluzione più elegante dal punto di vista tecnico non è necessariamente la migliore per il business. Un architetto che costruisce cattedrali di complessità per problemi che richiedono una capanna non è un genio incompreso, è semplicemente inadeguato al compito.

I professionisti sanno che la semplicità è difficile da raggiungere. Complicare le cose è facile, semplificarle richiede vera competenza. Sanno che l’automazione non è un lusso ma una necessità. Sanno che testare regolarmente in ambienti simili alla produzione non è spreco di tempo, ma investimento che ripaga abbondantemente quando conta.

La scelta che fa la differenza

I rilasci in produzione continueranno a essere momenti di verità dove tutto viene messo alla prova. Continueranno a esserci problemi imprevisti, momenti di panico quando componenti critici smettono di funzionare senza apparente motivo, occasionali crisi esistenziali sulla scelta di carriera.

Ma con il giusto approccio, con un team competente, con processi ben definiti, possono anche essere quei momenti di soddisfazione in cui vedi il frutto del tuo lavoro prendere vita e funzionare esattamente come previsto. Non c’è sensazione migliore di quella di chiudere il portatile dopo un rilascio andato liscio, uscire dall’ufficio e realizzare che fuori c’è ancora luce del giorno.

Questa è la differenza fondamentale. I primi vanno a casa in tempo per cena, con la soddisfazione del lavoro ben fatto. I secondi si ritrovano intrappolati in ufficio a notte fonda, ancora incerti se il sistema sopravviverà, circondati da cartoni di pizza fredda e lattine vuote, maledicendo le scelte che li hanno portati in quella situazione.

La preparazione fa tutta la differenza. Investire tempo nella simulazione degli scenari di produzione, nell’automazione, nel testing, nei piani di rollback non è perfezionismo inutile. È la linea che separa professionisti da incompetenti, rilasci noiosi da disastri epici, cene a casa da notti in ufficio.

E tu, da che parte vuoi stare? Vuoi essere quello che esce quando fuori è ancora giorno, o quello che si chiede se vedrà l’alba prima che il sistema crolli definitivamente?

La risposta a questa domanda determina non solo la qualità dei tuoi rilasci, ma la qualità della tua vita professionale. Perché alla fine, il codice è importante, l’architettura è importante, le tecnologie sono importanti. Ma niente è più importante della capacità di dormire sonni tranquilli sapendo che domani, quando gli utenti si collegheranno, il tuo sistema sarà ancora in piedi, funzionante, robusto.

E che tu non dovrai passare l’ennesima notte a sistemare disastri che potevano essere evitati con un minimo di buon senso applicato mesi prima.

Questo articolo è tratto da “Non funziona niente! – I progetti IT in crisi”, il primo libro della collana Nothing Works! — una tragicommedia aziendale per chi ha visto troppi Gantt chart trasformarsi in fiction.

Scopri la collana completa, gli altri libri e le prossime uscite su nothingworks.it

Vuoi il libro subito? Compralo su Amazon

Potrebbe interessarti anche

• Sistemista IT in una PMI: mansioni e competenze
• DIRETTORE ACQUISTI
• Perché documentare gli interventi IT potenzia la posizione del Sistemista?
• Da sistemista IT a IT Manager: un, possibile, percorso di carriera nell’ambito manifatturiero
• I problemi quotidiani di un Sistemista IT e come risolverli
• SISTEMISTA
• Quanto guadagna un Sistemista a Torino?
• SISTEMISTA IT
• Cosa fa un Sistemista in un Managed Service Provider: ruolo e giornata tipo
• Dieci clienti, un solo Sistemista: come si gestiscono le priorità in un Managed Service Provider