La complessità legacy è un premio che nessuno ha registrato

Questa serie continua a fare la stessa mossa. Scrivi la decisione. Fai rispettare il confine. Non moltiplicare le unità che devi governare. Metti l'isolamento nell'index. Codifica il giudizio. Colloca l'autorità dove il contesto già vive. Sei post, un solo istinto: togliere una garanzia dalla testa di una persona e costruirla in qualcosa che regge senza di lei.

Sotto tutto questo c'è una domanda a cui rispondo per istinto da anni e che non ho mai prezzato.

Ognuna di quelle mosse è un investimento. Un feature flag. Una migrazione expand-then-contract. Una chiave di deduplicazione. Un index partizionato per tenant. Ognuna compra la stessa cosa: la possibilità di sbagliare e tornare indietro comunque. E ognuna costa qualcosa da progettare, costruire, mantenere e alla fine rimuovere.

Qualcuno che passa la vita lavorativa sui costi IT dei CIO me l'ha posta nella forma che conta davvero. Quanto dovremmo essere disposti a spendere per rendere reversibili più errori? Chiaramente più di zero. Ma fino a dove?

È una buona domanda, e "dipende" non è una risposta.

Non stai comprando opzionalità, stai comprando un'assicurazione

L'inquadramento che me l'ha sbloccata è che la reversibilità non è una virtù. È una polizza contro l'errore.

Il che significa che si prezza come una polizza. Un premio è razionale solo rispetto al danno che copre. Nessuno assicura un bollitore. Tutti assicurano una casa. Quanto dovresti essere disposto a spendere per tenere reversibile una decisione dipende da due cose e da nient'altro: quanto costa sbagliare, e quanto è probabile che tu stia sbagliando.

Questo dà subito una forma. Investimento pesante sulle poche decisioni in cui sbagliare è insieme costoso e plausibile. Quasi niente sulle molte in cui è economico, o in cui hai quasi certamente ragione.

E nomina lo spreco, che non è la cosa di cui la maggior parte dei team si preoccupa. Lo spreco non è spendere troppo poco in sicurezza. È pagare lo stesso premio ovunque. Il team che mette un feature flag su ogni change sta comprando un'assicurazione contro rischi che non esistono, e il costo non sono solo i flag. È la pipeline più lenta, la ramificazione nel codice, i toggle accumulati che nessuno osa cancellare. Peggio: insegna a tutti che un flag è una cerimonia. Così quando arriva il change che ne aveva davvero bisogno, riceve la stessa scrollata di spalle degli altri quaranta.

La cautela uniforme sembra responsabile. È soltanto un modo di spendere che nessuno ha mai messo in discussione.

È economica alla giuntura e brutale dopo

La seconda cosa che rende strana l'economia della reversibilità è che il prezzo cambia a seconda di quando compri.

Un feature flag messo prima di rilasciare costa quasi nulla. Retrofittato dentro codice che ha assunto un solo percorso per un anno, è un progetto. Una migrazione expand-then-contract è quasi gratis se pianifichi la sequenza a monte, ed è archeologia se hai già eseguito la versione distruttiva e adesso ti serve di nuovo la forma vecchia.

Quindi la skill non è rendere tutto reversibile. È individuare presto quali decisioni se lo meritano, mentre la giuntura è ancora aperta e l'opzione costa ancora poco.

Ho il mio conto da pagare, su questo. Una volta ho scelto uno scheduler per un lavoro che aveva bisogno di una coda. Del guasto in sé ho già scritto altrove, ma dentro c'è una seconda lezione che all'epoca mi è sfuggita. Quella scelta è stata economica da fare e, nel momento in cui l'ho fatta, era economica da disfare. Quasi niente ci dipendeva ancora. Quando la produzione ci ha detto la verità, mesi dopo che lo sviluppo era stato dichiarato finito, lo stato del job viveva in due posti che si erano allontanati in silenzio, e invertire la scelta significava cambiare lo strumento sotto l'intero sistema.

La decisione non è diventata più sbagliata in quei mesi. È diventata più cara da disfare.

C'è anche un tetto

L'argomento fin qui pende tutto da una parte, quindi segno dove si ferma.

Oltre un certo punto, tenere qualcosa di reversibile costa più che impegnarsi e prendersi il risultato. L'opzionalità ha un costo di mantenimento, e l'eccesso di opzionalità ha un nome che riconoscerai: due ambienti di produzione accesi per due anni perché nessuno si impegna a spegnere il vecchio. La migrazione che è al novanta per cento da primavera scorsa. Il layer di astrazione che esiste per poter sostituire il database che non sostituirai mai.

Certe porte devono essere a senso unico di proposito. Decidere è il senso stesso del decidere. Una scelta su cui puoi sempre tornare indietro non è davvero una decisione, è un rinvio con una voce di budget attaccata.

Il premio non nasce con la decisione, si accresce dopo

Ecco la parte che il consiglio standard si perde, ed è la ragione per cui questo pezzo esiste.

L'inquadramento abituale dice: individua le porte a senso unico e rallenta su quelle. È un buon consiglio per le porte che sembrano a senso unico mentre ci sei davanti. Alcune lo sono davvero. Cancellare i dati di un cliente. Firmare un contratto quinquennale. Pubblicare un'API esterna.

Ma le decisioni che mi sono costate di più non erano affatto così. Erano genuinamente a doppio senso quando le ho prese. Niente dipendeva ancora dallo schema condiviso. Invertirlo sarebbe costato un pomeriggio e delle scuse tiepide.

È diventato una porta a senso unico circa sei mesi dopo, e non per qualcosa che avessi deciso io. Altri quattro team ci hanno costruito sopra, ognuno con una scelta locale perfettamente ragionevole, nessuna sbagliata, nessuno che consultasse nessuno, perché da dove stavano loro non c'era niente su cui consultarsi. Nessuno ha preso una nuova decisione architetturale. L'architettura è cambiata lo stesso.

Un architetto con cui scambio idee ci ha messo sopra un numero meglio di quanto avessi fatto io. Risparmiamo diecimila oggi rendendo qualcosa più difficile da invertire, e nessuno registra il premio che abbiamo appena accettato. Cinque anni dopo quel vincolo costa mezzo milione per essere rimosso, e tutti lo chiamano complessità legacy.

Quel divario non è un errore di prezzo al momento della decisione. È lì la trappola. Il premio non esisteva ancora quando ho scelto. È stato fabbricato dopo, da ogni scelta successiva che ha dato per scontato che la cosa difficile da invertire sarebbe rimasta dov'era. L'accoppiamento che trasforma diecimila in cinquecentomila non era stato creato nel momento in cui qualcuno avrebbe potuto scriverlo, e nessuna metrica prezza una dipendenza che ancora non esiste.

La complessità legacy è per lo più questo. Non un catalogo di decisioni sbagliate, ma un mucchio di decisioni ragionevoli di cui nessuno stava tracciando il costo di inversione.

Misurabile al margine

Se una parte non si può prezzare, vale la pena essere precisi su quale parte si può.

La metà operativa è visibile al momento della decisione, e si legge sul change stesso invece di essere giudicata in riunione. Tocca dati che non puoi ricreare? Fissa una forma su cui altri costruiranno, uno schema, un'interfaccia, un contratto di evento? Ti impegna verso qualcosa fuori dall'azienda, un cliente, un fornitore, un regolatore? Queste domande hanno una risposta il giorno stesso, e sono quelle su cui vale la pena pagare un premio.

La metà che si accresce non è visibile, e fingere il contrario è il modo in cui finisci con un esercizio di punteggio che produce numeri sicuri di sé su niente.

Ma non è invisibile per sempre, ed è qui che ho trovato qualcosa di utilizzabile. L'accoppiamento tecnico si annuncia come chiamanti, e un dependency graph ti mostra almeno quello. Ciò che un dependency graph non ti mostrerà mai è che un contratto con un fornitore ormai assume l'integrazione attuale, o che un team operativo si è riorganizzato in silenzio attorno a un workaround, o che le due persone che capivano l'alternativa se ne sono andate.

Quei costi vivono tra le funzioni, e ogni strumento che possediamo punta a una funzione sola. Così il proxy di cui ho imparato a fidarmi è più grezzo e le attraversa tutte: quante persone devono dire di sì adesso. Quando una cosa che un tempo cambiavi dentro uno sprint ora richiede il procurement, altri due team e uno slot in una riunione di steering, il costo di inversione si è già spostato. È osservabile mesi prima che qualcuno possa metterci una cifra, e per vederlo non serve un nuovo processo di governance. Serve accorgersene.

Cosa fare della metà che non puoi prezzare

Non puoi prezzare il premio intero nel momento in cui lo accetti. Puoi registrare che ne hai accettato uno.

"Abbiamo scelto questo. Crediamo sia economico da invertire, perché non ci dipende ancora niente." Quella frase richiede dieci secondi e non è documentazione fine a sé stessa. È un'affermazione, e un'affermazione è una cosa che il mondo può smentire più tardi. Senza, non c'è niente da invalidare, ed è esattamente il motivo per cui anni dopo il costo riemerge come un dato di fatto senza padre, invece che come una decisione che qualcuno ha preso e che qualcun altro avrebbe potuto riaprire.

Il che risponde finalmente alla domanda su quando guardare di nuovo. Non su un calendario. All'anniversario di una decisione non succede niente, e una review schedulata è un rituale che una persona deve ricordarsi di tenere: la prima si fa perché è nuova, la terza slitta di un trimestre, e sei tornato al punto di partenza. E nemmeno su un conteggio grezzo di dipendenze, perché il numero mente. Venti consumer di un'interfaccia stabile non sono niente. Tre che hanno scavalcato l'interfaccia e costruito sui suoi interni sono il caso caro.

Il trigger è il momento in cui la tua affermazione di reversibilità smette di essere vera. E la cosa che vale la pena costruire è qualunque cosa se ne accorga al posto tuo.

La regola che ti lascio

Ogni post di questa serie ha tolto una garanzia dalla testa di qualcuno e l'ha messa da qualche parte dove regge senza di lui. Questo parla di quanto costa e di quando pagare.

Spendi dove sbagliare è insieme costoso e plausibile, e non spendere quasi niente altrove, perché la cautela uniforme è solo spreco con l'espressione seria. Spendi presto, mentre la giuntura è ancora aperta, perché la stessa protezione costa cento volte tanto una volta che la cosa ha fatto presa. Fermati prima che l'opzionalità diventi un modo per non decidere mai.

E quando accetti un premio, scrivi una volta perché pensavi che questo sarebbe stato economico da disfare. Non per l'audit trail. Per chi scoprirà, forse tu, fra tre anni, che ha smesso di essere vero, e non saprà dire se qualcuno lo avesse mai saputo.

Il che lascia la domanda a cui vorrei davvero una risposta sul tuo sistema. Di tutte le decisioni che oggi descrivi come reversibili, quante lo sarebbero ancora se ci provassi questo trimestre?