La Colonna di Dieci Minuti

Narratore: Benvenuti a Allineiamoci Offline. Questo podcast è prodotto con l'ausilio di voci sintetiche. È lunedì mattina. Il team è riunito per l'allineamento settimanale. Entra il Commerciale.

Commerciale: Ciao ragazzi! Allora, brevissimo aggiornamento. Ho parlato con il cliente e hanno una richiesta minuscola per il report mensile. Vogliono solo aggiungere una colonna con il codice fiscale dell'utente finale. Una modifica di dieci minuti, giusto? Gliel'ho già accennato, diciamo che per venerdì è pronta.

Product Owner: Dieci minuti? Aspetta, il report è quello critico per la compliance, giusto? Abbiamo già lo sprint pieno di bug della release precedente, non so come incastrarla.

Commerciale: Dai, è solo una colonna! Non entriamo nel tecnico, ma logicamente il dato c'è nel database, basta stamparlo. Non complicatela!

Product Owner: Ma scusate, se il dato è già nel database, perché non è mai stato incluso nei report precedenti? Il cliente dice che ne ha bisogno da mesi.

Commerciale: Eh, vedi, è una questione di percezione. All'inizio non era una priorità, poi hanno cambiato il loro processo interno. Ma ora che lo hanno chiesto, è diventata una cosa fondamentale. Per loro è un click, per noi è... beh, è un click, no?

Product Owner: Ma un click per chi? Il cliente non ha accesso al database, deve ricevere il file PDF via email ogni primo del mese. Se aggiungiamo una colonna, dobbiamo cambiare il template, aggiornare i parametri di generazione e testare che l'impaginazione non esploda.

Commerciale: Appunto, un piccolo accorgimento grafico! Guardate che sono persone ragionevoli, non pretendono la perfezione tipografica, vogliono solo vedere quel maledetto codice fiscale per evitare sanzioni dall'Agenzia delle Entrate. È un valore aggiunto enorme per loro, quasi un upgrade gratuito!

Junior Developer: Ci penso io, è davvero un campo in più.

Narratore: Due ore dopo. Il Junior Developer ha aperto il codice. È accompagnato dal Senior Developer.

Junior Developer: Scusa, Senior... stavo cercando il modulo del report e ho trovato una procedura chiamata 'Report_Finale_V3_NON_CANCELLARE'. È scritta in... cosa è questo? Non è SQL, non è Java...

Senior Developer: È un dialetto di COBOL personalizzato. L'ha scritto uno stagista nel duemilaquindici che poi è sparito nel nulla. Non toccarlo.

Junior Developer: Ma se dobbiamo solo aggiungere il codice fiscale? Dove lo prendo?

Senior Developer: Vedi, il problema è che quel database di cui parlava il Commerciale è l'anagrafica. Ma il report non legge l'anagrafica. Legge un'estrazione piatta che viene filtrata da una logica di business scritta in un'epoca in cui i cloud erano solo nuvole in cielo.

Junior Developer: Quindi per aggiungere un campo devo modificare la logica di estrazione, il formato del file intermedio e poi la procedura in quel... COBOL modificato?

Senior Developer: Esatto. E buona fortuna a trovare dove finisce un record e ne inizia un altro in quel file. Non ci sono delimitatori standard, usano una combinazione di spazi e tabulazioni che sembra un codice Morse. Ah. Il codice fiscale non è nel database del report. Viene calcolato da un file di testo che viene generato da un altro script, che a sua volta legge un CSV esportato manualmente da un altro sistema ogni martedì alle tre del mattino. È un workaround che avevamo fatto per un'emergenza sei anni fa.

Junior Developer: Ma perché non lo abbiamo reso strutturale?

Senior Developer: Perché era venerdì sera.

Junior Developer: Aspetta, quindi se leggo bene questo commento nel codice... c'è scritto 'FIX TEMPORANEO - TOGLIERE APPENA POSSIBILE - MARZO 2017'. Siamo sicuri che questo sia l'unico modo per recuperare il dato?

Senior Developer: Sì, è l'unico. L'alternativa era riscrivere il modulo di integrazione, ma il budget era finito e il cliente voleva il report entro mezzogiorno. Quel commento è l'unica traccia di civiltà rimasta in questo modulo. È come un monumento all'ottimismo di chi pensava che un giorno avremmo avuto tempo per pulire.

Narratore: Il team si riunisce di nuovo in call. Si aggiunge il Software Architect.

Software Architect: Ho ascoltato i problemi del Junior. Ragazzi, siamo davanti a un'opportunità incredibile. Non possiamo limitarci a aggiungere una colonna a un monolite legacy che sfida le leggi della logica. Dobbiamo approfittarne per migrare l'intero modulo a un'architettura a eventi, disaccoppiando la generazione dei dati dalla presentazione attraverso un event-bus asincrono.

Product Owner: Un'architettura a eventi? Ma l'obiettivo è il codice fiscale per venerdì! Quanto tempo serve per questa... cosa?

Software Architect: Per farlo correttamente, secondo gli standard di scalabilità moderni, direi tre mesi. Ma avremmo un sistema a prova di futuro.

Senior Developer: Tre mesi per una colonna.

Software Architect: Esattamente! Tre mesi per eliminare definitivamente questa dipendenza tossica da file di testo. Immaginate la pulizia concettuale: un'architettura reattiva, dove il dato fluisce in tempo reale. Non più attese fino alle tre del mattino per un CSV, ma un flusso continuo di valore.

Product Owner: Sì, la pulizia concettuale è fantastica, ma io ho un cliente che sta urlando al telefono. Non posso dirgli che il suo codice fiscale è in viaggio verso un'architettura reattiva per i prossimi novanta giorni!

Software Architect: Capisco l'urgenza, ma pensate al debito tecnico! Se aggiungiamo un'altra patch su questo castello di carte, tra un mese non riusciremo più nemmeno ad avviare il server. Dobbiamo parlare di domini, di bounded contexts. Il codice fiscale appartiene al dominio dell'utente, non a quello della reportistica!

Product Owner: I domini non pagano le penali contrattuali, Architetto! Io ho bisogno di una colonna, non di una lezione di Domain Driven Design!

Narratore: Alla call si aggiunge il CTO.

Chief Technology Officer: Buongiorno a tutti! Sento parlare di tre mesi e di architetture a eventi. Mi piace l'approccio. Vedete, questo non è più un semplice problema di reportistica, ma un vero e proprio percorso di trasformazione digitale. Stiamo ottimizzando il valore del dato per massimizzare il time-to-market delle future feature. Trasformiamo questa criticità in un pilastro della nostra strategia di modernizzazione cloud-native.

Product Owner: Sì, bellissimo, ma il cliente vuole il report venerdì o ci toglie il contratto!

Chief Technology Officer: Il pragmatismo è fondamentale. Architetto, proceda con il piano di modernizzazione a lungo termine. Per il venerdì, Senior, trovi una soluzione agile per dare visibilità al cliente. Chiamiamolo 'MVP di transizione'.

Junior Developer: Ma scusate, se facciamo l'MVP di transizione, non rischiamo di creare un altro di quei workaround che Senior diceva essere nati di venerdì sera?

Senior Developer: Junior, benvenuto nel mondo reale. Qui non creiamo bug, creiamo 'soluzioni temporanee a lungo termine'.

Chief Technology Officer: Esatto, chiamiamolo 'debito tecnico strategico'. È un investimento che faremo ora per garantire la delivery immediata, che poi estingueremo con la fase di modernizzazione. È un'operazione di leva tecnologica.

Narratore: Venerdì pomeriggio. Il report è stato consegnato. Il team ha implementato un ulteriore script Python che legge il CSV, concatena le stringhe e sovrascrive il file di output finale a mano ogni ora.

Senior Developer: Perfetto. Ora abbiamo un sistema legacy, un file di testo, un script Python e un'architettura a eventi fantasma. Non vedo l'ora di vedere chi dovrà manutenere questo capolavoro tra un anno.