C'è un modo affidabile per riconoscere il software costruito per impressionare chi lo scrive invece che per servire chi lo possiede: contare le tecnologie. Il sistema con quattro database, due sistemi di code e un framework uscito la primavera scorsa non è stato progettato: è stato collezionato. E il collezionista quasi mai paga il conto della manutenzione.
Il costo reale della tecnologia entusiasmante
La tecnologia nuova si fa pagare tre volte. La prima negli imprevisti che nessuno ha ancora catalogato: modalità di guasto su cui non esiste nemmeno un articolo, scoperte alle due di notte nel suo sistema in produzione. La seconda nelle assunzioni: ogni scelta esotica riduce il bacino di persone in grado di mantenere il sistema e ne alza il prezzo. La terza nella longevità: il framework entusiasmante di quest'anno ha una probabilità su due di essere abbandonato entro cinque anni - gli strumenti collaudati hanno già superato le loro estinzioni di massa.
I tre costi si sommano l'uno all'altro. Il database esotico si guasta in un modo non documentato, cosa a cui si sopravvive - se non fosse che l'unico ingegnere che lo capiva se n'è andato in primavera e la ricerca del sostituto è al quarto mese, perché il bacino di candidati per quella competenza specifica è un errore di arrotondamento. Nel frattempo il framework su cui poggia ha annunciato la sua «nuova entusiasmante direzione», che nel linguaggio dei fornitori significa riscrivere tutto ciò che è stato costruito sulla versione precedente. Non erano tre rischi distinti: era un solo rischio, comprato tre volte.
Questi costi arrivano dopo che l'agenzia se n'è andata. È esattamente per questo che le agenzie sono strutturalmente attratte dalla tecnologia entusiasmante: il beneficio sul curriculum è loro, il conto della manutenzione è suo. Allineare quegli incentivi è un problema di disegno contrattuale tanto quanto di ingegneria: è anche per questo che diamo una garanzia su ciò che consegniamo e ci offriamo di gestire ciò che costruiamo.
Come nasce la collezione
Nessuno parte con l'intenzione di costruire un sistema non manutenibile: si stratifica attraverso decisioni singolarmente difendibili. Un ingegnere vuole una tecnologia sul proprio curriculum, e il progetto è l'unico posto dove ottenerla. Un intervento a una conferenza fa sembrare buona pratica, per un team di sei persone, un'architettura pensata per un'azienda con mille ingegneri. Un diagramma a microservizi sembra più professionale di un onesto monolite. Ogni scelta aggiunge un pezzo in movimento, e i pezzi in movimento si moltiplicano: due database non costano il doppio di uno - costano il secondo database più la sincronizzazione fra i due, per sempre.
La difesa è una regola noiosa applicata al momento della revisione: ogni tecnologia che esce dallo stack di default deve guadagnarsi l'ingresso con un requisito misurabile che il default non riesce a soddisfare. «È più scalabile» non conta senza un numero. «Potremmo averne bisogno più avanti» è una ragione per aggiungerla più avanti. L'onere della prova sta sulla novità, mai sulla scelta noiosa - perché solo una delle due ha uno storico da mostrare.
L'innovazione è un budget. Lo spenda sul suo prodotto, dove i clienti lo vedono - non sulla sua infrastruttura, dove lo vedono solo i suoi ingegneri.
Noioso ≠ vecchio
Noioso non vuol dire legacy. PostgreSQL, TypeScript, React, i servizi cloud diffusi: sono moderni, sviluppati attivamente ed estremamente capaci. Ciò che li rende noiosi è che i loro spigoli sono documentati, le loro modalità di guasto sono note e un milione di team ha già sbattuto contro i problemi contro cui sta per sbattere lei. Noioso significa prevedibile, e la prevedibilità è ciò che si compra quando si pagano tariffe senior.
Qui si nasconde un segnale sulle assunzioni che i titolari d'azienda leggono sistematicamente al contrario. Gli ingegneri junior inseguono stack interessanti; gli ingegneri senior inseguono problemi interessanti e scelgono di proposito strumenti sonnolenti, perché hanno pagato di persona il conto delle due di notte per l'entusiasmo. Un team che le propone un'architettura noiosa non è poco ambizioso: le sta mostrando le proprie cicatrici. L'ambizione va in ciò che il sistema fa, non in ciò di cui è fatto.
La disciplina ha un corollario: quando il budget di innovazione lo spendiamo davvero - come nei sistemi AI, dove la frontiera si sposta sul serio ogni trimestre - isoliamo la parte entusiasmante dietro interfacce noiose, la teniamo sostituibile e la avvolgiamo in un sistema di valutazione. Il raggio d'azione della novità deve essere un modulo, mai un'architettura.
In pratica significa che il fornitore del modello sta dietro un'interfaccia di cui il resto del sistema non sa nulla, così sostituirlo è un cambio di configurazione, non una migrazione. Significa un sistema di valutazione che assegna un punteggio a ogni modello candidato sui suoi casi reali, così la decisione di sostituirlo è una misura, non una dichiarazione di moda. La parte entusiasmante resta entusiasmante - semplicemente non le è concesso rendere interessante il resto del sistema.
Lo stack di default, e come si cambia
Lo strumento pratico dietro tutto questo è uno stack di default messo per iscritto: l'elenco breve delle tecnologie che un sistema nuovo usa a meno che qualcuno non dimostri il contrario. Un database primario. Un linguaggio di backend che tutto il team legge. Un framework di frontend. Servizi cloud gestiti al posto di qualsiasi cosa auto-ospitata - la scelta noiosa, sul piano operativo, è pagare il fornitore cloud perché stia lui di reperibilità. L'elenco sta su un cartoncino, ed è proprio questo il punto: ogni aggiunta deve sembrare costosa, perché lo è.
Cambiare il default si può - passando dalla porta principale. Un breve documento scritto: il requisito che il default attuale non soddisfa, il numero che lo dimostra, il percorso di migrazione in entrata e la via d'uscita. Poi una prova su qualcosa di non critico, prima che qualcosa rivolto ai clienti ne dipenda. I team che seguono questo rito adottano forse una tecnologia nuova all'anno, deliberatamente, e quella resta. I team che non lo fanno ne adottano cinque per caso e ne tengono due - le altre tre restano comunque in produzione, migrate a metà, a farsi pagare un affitto per sempre.
Domande da fare al prossimo fornitore
Chi lo manterrà al terzo anno, e quanto costerà? Quanto è ampio il bacino di assunzione per questo stack - e che cosa succede ai nostri tempi quando uno di questi framework viene abbandonato? Perché questo secondo database, in numeri? Che aspetto ha il runbook di reperibilità, e potrebbe seguirlo un ingegnere che non ha costruito il sistema? Se le risposte sono vaghe, l'architettura è una passività travestita da demo.
La tecnologia noiosa è il motivo per cui il software resta un asset invece di diventare un progetto di ricerca con una pagina di login - ovvero: è un lusso che la sua azienda può permettersi proprio perché non ne ha l'aspetto. Il premio non sta negli strumenti. Sta nella moderazione.