L'autore ha trascorso buona parte della sua vita professionale cercando di capire se il problema nei progetti IT fosse il codice, i processi o semplicemente... le persone. Dopo anni passati tra sprint infiniti, task manager mai aggiornati e riunioni in cui nessuno sa perché è lì, ha deciso di iniziare a scrivere. Non per insegnare qualcosa – non è così presuntuoso – ma per documentare l’assurdità sistematica che regola il mondo del lavoro tecnologico.
 
 Il suo curriculum assomiglia a una mappa caotica del mondo IT: sviluppatore per necessità, analista per errore, project manager per disperazione. Ha lavorato in startup che si credevano unicorni e in aziende consolidate che comunicavano ancora via fax. Ha scritto codice, lo ha spiegato ai clienti, poi ha fatto finta di capirli quando volevano esercitare il diritto di recesso.
 
 È convinto che l’ironia sia l’unico strumento realmente efficace per descrivere l’IT contemporaneo, perché la realtà, così com’è, sarebbe troppo crudele da accettare senza riderne. Nei suoi scritti racconta ciò che molti pensano ma pochi osano dire: che dietro ogni buzzword c’è spesso una grande confusione, e dietro ogni "best practice" si nasconde una verità scomoda.
 Insoddisfatto dall'uso dell'intelligenza artificiale generativa nella scrittura del software, ha pensato di iniziare a usarla per scrivere ed illustrare (male) i libri.&nbsp; 
 Non ama definirsi scrittore, preferisce "testimone esausto". Scrive per chi ha sopportato l’ennesima call inutile, per chi è stato assunto come esperto ma trattato come stagista, per chi ha imparato a parlare fluentemente il burocratese aziendale senza mai capirlo davvero.
 
 Oggi continua a lavorare nel settore, nonostante tutto. Forse per masochismo, forse per avere materiale per nuovi libri. Ma di sicuro, con una tastiera in mano, ha trovato un modo per vendicarsi.&nbsp;

Roberto Cappa

Scopri l’autore che racconta con ironia feroce il caos nei progetti IT, tra analisi disfunzionali, sviluppo disordinato e vita d’azienda surreale.

Roberto Cappa - Autore ironico sul mondo IT e aziendale

"Non funziona niente!" non è un libro di project management. È più un esorcismo. Un manuale di auto-difesa passiva-aggressiva per tutti coloro che, almeno una volta nella vita, hanno guardato un Gantt chart e pensato: “Ok, ma chi ha autorizzato questa follia?”. Dimentica i manuali seriosi pieni di diagrammi, acronimi e consigli scritti da chi non ha mai visto un utente reale. Questo libro è una raccolta spietata di episodi vissuti, raccontati con uno stile irriverente, cinico al punto giusto, ma profondamente onesto. L’autore – sopravvissuto a decine di progetti IT condotti con l’infallibile metodo “tanto in qualche modo lo facciamo” – ci accompagna nei meandri del management folle. In queste pagine troverai:
 <ul><li>l’arte di raccogliere requisiti tramite interpretazione libera di frasi dette a voce, in riunioni dove nessuno prende appunti;</li><li>team che passano mesi a personalizzare software perfettamente funzionante fino a renderlo inutilizzabile;</li><li>l’intramontabile paura di essere “early adopter“… anche per tecnologie lanciate nel 2012;</li><li>naturalmente, l’ossessione per la scalabilità infinita – a patto che costi zero e non richieda manutenzione;</li><li>la leggendaria tecnica della “crisi pianificata”, dove si parte in pochi, in ritardo, e si finisce in dodici a lavorare gratis nei weekend – tutto per l’obiettivo, ovviamente;</li><li>il mito del fullstack developer onnisciente, invocato per risparmiare assumendo uno che “sappia fare tutto”, cioè niente bene;
</li><li>lo stile “diversamente Agile”, dove si seguono tutte le cerimonie Scrum… senza capirne il senso, ma con una bella bacheca colorata;</li><li>l'ossessione della riunione: ogni problema, anche il più banale, merita un tavolo tecnico, una call plenaria e, perché no, una task force;</li><li>la farsa delle priorità urgenti, dove ogni pulsante diventa una bomba da disinnescare e tutto è “emergenziale” – tranne il buon senso;</li><li>l’emozione di scoprire all’una di notte che il piano di rollback esiste solo nei sogni del CTO;</li><li>un esilarante bestiario degli utenti che aprono ticket con messaggi tipo “non va”.</li></ul>Popolato da personaggi indimenticabili come Ferdinando, il manager che pontifica di blockchain senza sapere che non è un cocktail, Margherita, l’utente che sa tutto tranne perché fa quello che fa, e Vincenzino, lo sviluppatore brillante che inizia a spegnersi dopo la terza call alle 9 del mattino, questo libro è una vera e propria tragicommedia aziendale.
 Ogni capitolo si apre con una frase realmente pronunciata da qualcuno (tra cui, inspiegabilmente, chi aveva potere decisionale). Il libro non ti darà soluzioni. E va benissimo così. Perché il vero scopo è farti ridere, riflettere e – perché no – sentire meno solo. È dedicato a chi lavora nell’IT, ma anche a chi lo subisce. È un tributo ironico e dissacrante a un settore che riesce a essere all’avanguardia e preistorico allo stesso tempo. Se hai mai sentito la frase “Tanto il software lo fa da solo”, questo libro è per te. Se l’hai detta… beh, è ancora più urgente che tu lo legga.
 
 Acquistalo ora. È l’unico progetto ben progettato che leggerai quest’anno.
 
 Disclaimer legale: ogni riferimento a persone reali è puramente intenzionale. Se ti riconosci, non preoccuparti: non sei solo. Ce l’abbiamo con tutti.

Introduzione

Cos'è e com'è strutturato questo libro

Il progetto IT

Così è già deciso, l'udienza è tolta! - L'analisi di fattibilità

Fai tu una minuta della riunione? - L'analisi funzionale

Abbiamo sempre fatto così - La raccolta dei requisiti

La funzione incarnata - Le user stories

È (quasi) sempre così - La definizione delle specifiche

E il codice fiscale non ce lo metti? - La definizione del modello dati

È troppo tecnico - La documentazione di analisi

Quanto ci vuole? Ma soprattutto, quanto ci costa? - La stima

Le avete messe le penali? - Il contratto di fornitura

Innoviamo nella tradizione - La scelta delle tecnologie

Il matrimonio combinato - La partnership

Possiamo metterci il nostro logo? - Make or buy

Non saremo degli early adopter? - Essere al passo coi tempi

È solo qualche milione - La scalabilità e le performance

A prova di acaro - La sicurezza

Pennello e tavolozza - UI/UX e design dell'interfaccia utente

Integrazione: è fondamentale, ma dopo - Gli integration pattern

Non ingegnerizziamo troppo - La complessità

Bisogna centralizzare - I design pattern

Microliti - Il disegno dell'architettura

Mashup nell'era dei microliti - I microfrontend

ORM: Object-Relational Mayhem - L'accesso ai dati

Il cloud è solo il computer di qualcun altro - L'infrastruttura

Bisogna raggiungere l'obiettivo - La pianificazione

Il mito del fullstack developer - Le figure professionali

Diversamente agili - Il metodo di sviluppo

Per fare un tavolo ci vuole il legno - Lo stato avanzamento lavori

La sindrome del fornitore fantasma - La consulenza

È urgente ed emergenziale - La gestione delle priorità

Sottosviluppo con l'AI - I nuovi strumenti a supporto dello sviluppatore

Nascondo il bug con una grossa mano - Il test e il debug

Intermezzo - La triade maledetta

Fuori è ancora giorno - Il rilascio in produzione

Copiamo i file su un server in FTP - DevOps e CI/CD

Che succede? - Il monitoraggio

Non funziona niente! - L'assistenza e il ticketing

Abbiamo i backup? - La gestione delle emergenze e il disaster recovery

Qualcuno ha un manuale? - La documentazione

Obsolescenza non programmata - La manutenzione evolutiva

I segnali di allarme

Epilogo

Ringraziamenti (e supplica finale)

Libro cartaceo

eBook Kindle

English edition

Microliti Il disegno dell'architettura I microservizi - l'equivalente architetturale di decidere di trasformare la propria casa in un condominio, dove ogni stanza diventa un appartamento indipendente e per fare colazione devi chiamare un'API al frigorifero in cucina. Permettetemi di spiegare perché questa apparentemente brillante idea può (ma non deve) trasformarsi in un incubo logistico. Da ormai qualche anno, ben prima dell'avvento dello sviluppo basato su AI, la moda dei microservizi ha conquistato ogni realtà IT, anche quelle di dimensioni medie o piccole. Ormai sembra che ogni azienda debba, a un certo punto, abbracciare l'idea dei microservizi. Naturalmente, i microservizi sono un po' come l'agile, come vedremo in seguito: farli davvero bene è una sfida immensa. Rispettare tutte le regole e le linee guida richiede uno sforzo notevole, che spesso si scontra con i limiti di tempo e di energia a disposizione. Di conseguenza, l'overhead necessario per realizzare un sistema a microservizi è noto e, in molti casi, non sostenibile nemmeno per le aziende più strutturate o con team molto vasti. Il passaggio dal monolite ai microservizi ricorda un po' la storia della persona a dieta che passa dal mangiare un intero panettone a mangiare trenta fettine sottili dello stesso panettone - tecnicamente hai il cibo, ma le calorie sono sempre quelle. Anzi, nel mondo tecnologico, in realtà le calorie sono aumentate. porzionato Ecco perché anni fa ho coniato il termine , cioè un microservizio realizzato principalmente per poter dire "Abbiamo fatto i microservizi", ma che non rispetta buona parte delle best practice che dovrebbero governarli. Quindi di fatto diventa un vecchio monolite, con troppe responsabilità. Ma è un monolite piccolo, ben travestito da microservizio. Un , insomma. Una parola che suona come una condizione medica, e forse lo è, nel senso patologico del termine. I microservizi fatti così servono comunque a far alzare la testa a chiunque si vanti che il proprio sistema richiede il deployment di ben cinquantaquattro componenti software diversi. microlite microlite L'overhead necessario per gestire un'architettura a microservizi è come decidere di andare a fare la spesa in ventidue negozi diversi invece che in un unico supermercato. Sì, teoricamente ogni negozio è specializzato nel suo settore, ma alla fine ti ritrovi a fare il giro della città per comprare ingredienti che prima trovavi tutti nello stesso posto. Come se non bastasse, scopri che alcuni di questi negozi sono chiusi da mesi, altri vendono praticamente le stesse cose, e di alcuni ti sei dimenticato persino l'esistenza. È facile notare come pochi team agili riescano a seguire alla lettera le regole dell'agile, e altrettanti architetti software possano affermare con sicurezza che i loro microservizi rispettano tutte le linee guida previste; francamente, io non ne ho ancora conosciuti. La necessità di abbandonare il monolite era ormai palese ben prima dell'era dei microservizi: già si capiva che deployare backend, frontend e database sullo stesso server non era una buona idea. Oggi, però, abbiamo portato questo concetto all'estremo opposto. Naturalmente, uno di questi microliti potrebbe gestire le logiche di business di tre quarti del sistema, mentre altri dieci risultano praticamente inutili; anzi, a pensarci bene, forse tre o quattro di questi componenti non vengono mai chiamati, e magari ne basterebbero trenta, ma qualche volta ci si dimentica di toglierli. Alla fine, ci vogliono tre ore per deployare tutti i pezzi: cosa vuoi che cambi? Ed è in questo contesto che riecheggia, con una nota amara di verità, la celebre affermazione di Martin Fowler: "Don't even consider microservices unless you have a system that's too complex to manage as a monolith". Per noi italiani suona come "Non comprare una fuoriserie sportiva se devi solo andare a fare la spesa". Eppure, eccoci qui, con aziende che implementano architetture a microservizi come se fossero figurine da collezione: "Ehi, guarda! Ho appena deployato il mio trentesimo microservizio!" - "Ah sì? E cosa fa?" - "Non ne sono sicuro, ma fa molto enterprise!" La verità è che molti di questi sono più . Alcuni fanno il lavoro di tre persone mentre altri passano le giornate a guardare serie tv, come in ogni ufficio che si rispetti. E poi ci sono quelli che non vengono mai chiamati, come quel cugino di terzo grado che inviti al matrimonio solo per cortesia. microservizi servizi con complessi di inferiorità Il problema non è l'idea dei microservizi in sé, che resta valida quando applicata nel contesto giusto. Non tutti i sistemi necessitano di essere spezzettati in quarantadue componenti. Ma almeno possiamo dire di essere e scalabili. E se qualcuno osa suggerire che forse, solo forse, stiamo esagerando, possiamo sempre rispondere con un altezzoso "È che tu non capisci i benefici di un'architettura distribuita" - anche se l'unica cosa veramente distribuita è la nostra pazienza nel gestire tutto questo. cloud native La gestione distribuita è proprio il primo grande ostacolo. In una architettura classica, se qualcosa va storto, è come cercare un oggetto in casa propria: sai più o meno dove guardare. Con i microservizi, è come cercare le chiavi in decine di case diverse, mentre ogni casa ha il proprio sistema di allarme, le proprie regole e parla una lingua diversa. Il debugging diventa un'avventura degna di Indiana Jones, dove ogni log è un indizio in una caccia al tesoro distribuita. I costi operativi sono come decidere di trasformare ogni stanza della propria casa in un mini-appartamento: ogni spazio ha bisogno del proprio impianto elettrico, idraulico, di riscaldamento. Kubernetes, Docker, strumenti di monitoring - come assumere un amministratore di condominio, un portiere e un manutentore per ogni singola stanza. E indovinate chi paga tutte queste spese? La latenza di rete introduce ritardi che prima non esistevano. È come se per passare il sale a tavola dovessimo spedirlo per posta: tecnicamente funziona, ma non è proprio efficiente. E se la spedizione fallisce? Ecco che servono sistemi di retry e altre complicazioni che erano semplicemente non necessarie. Molte aziende creano microservizi come se stessero giocando a Jenga al contrario: invece di rimuovere pezzi con attenzione, aggiungono servizi fino a quando la struttura non crolla sotto il proprio peso. La sicurezza in un ambiente distribuito è un altro incubo. È come dover controllare i documenti di identità non solo all'ingresso dell'edificio, ma a ogni porta di ogni stanza. Un singolo token dimenticato, un'API mal protetta, e il tuo sistema diventa più permeabile di un colabrodo. La verità è che i microservizi sono impressionanti sulla carta, ma prima di buttarsi in quest'avventura, bisogna chiedersi onestamente: la nostra architettura, che pure non è un monolite, ma è già ben organizzata in diversi servizi cloud-native, è davvero così ingestibile? Abbiamo le risorse e le competenze per gestire la complessità? O stiamo solo seguendo una moda, come quelle persone che comprano attrezzatura da palestra professionale per fare tre flessioni al mese? Nell’ormai lontano 1967, Melvin Conway formulò una legge tanto semplice quanto devastante: "Le organizzazioni progettano sistemi che sono copie della loro struttura di comunicazione". In parole povere: se hai quattro team che non si parlano tra loro, avrai quattro servizi che non si parlano tra loro. È forse l'unica legge dell'informatica che gli executive capiscono istintivamente ma fingono di non conoscere. La Conway's Law è l'elefante nella stanza di ogni discussione architetturale. Possiamo parlare quanto vogliamo di microservizi, architetture esagonali ed event sourcing, ma alla fine il nostro sistema rifletterà fedelmente i giochi di potere, le rivalità interdipartimentali e i silos organizzativi della nostra azienda. Ho assistito a dibattiti accesi su pattern architetturali che erano in realtà guerre su chi avrebbe controllato quale parte del sistema. Ho visto "decisioni tecniche" che erano trasparenti tentativi di espandere il proprio territorio organizzativo. Ho osservato API disegnate non per facilità d'uso, ma per replicare confini dipartimentali. La realtà è che il vostro organigramma è la vostra architettura. Quel CTO che sogna un'elegante architettura a microservizi mentre gestisce un'organizzazione monolitica e verticale sta vivendo in un mondo di fantasia. Paradossalmente, alcune aziende hanno iniziato a sfruttare questa legge a proprio vantaggio, riorganizzandosi per ottenere l'architettura desiderata invece di tentare l'impossibile percorso inverso. I segnali che la Conway's Law sta agendo nella vostra organizzazione sono evidenti: servizi che non hanno alcun senso dal punto di vista tecnico ma riflettono perfettamente la struttura dei team; interfacce inutilmente complicate tra componenti gestiti da dipartimenti rivali; e quella strana sensazione durante i meeting architetturali che state assistendo a una partita a scacchi. La morale? I microservizi possono essere la soluzione giusta, ma solo quando il problema è quello giusto. La best practice per fallire con stile? Un nuovo progetto con due sviluppatori? Devi fare tutto a microservizi.

"Non funziona niente!" non è un libro di project management. È più un esorcismo. Un manuale di auto-difesa passiva-aggressiva per tutti coloro che,