Della proprietà si parla di solito come di un assetto finanziario. Chi detiene il capitale, chi beneficia dei guadagni, chi decide un’eventuale uscita. Sono domande importanti, ma non sono l’oggetto di questa nota.
Costruiamo e gestiamo la nostra tecnologia perché la proprietà determina l’orologio. E l’orologio determina l’ingegneria.
Ogni sistema segue l’orologio di qualcuno
Il software viene sempre costruito in funzione di un’aspettativa su quando qualcosa dovrà essere vero, e quell’aspettativa si propaga fino alle decisioni tecniche.
Un sistema costruito nell’ambito di un contratto segue l’orologio del contratto. Il lavoro viene definito in base a ciò che si può consegnare prima della sua scadenza, il che è ragionevole per entrambe le parti e strutturalmente ostile al tipo di infrastruttura che si ripaga solo dopo diversi anni. Nessuno prevede una voce di spesa per il modello di dati che renderà economico il quarto anno.
Un sistema costruito per essere venduto segue l’orologio dell’acquirente. È plasmato da ciò che si può mostrare al momento della vendita, e ne deriva una forte preferenza per ciò che è dimostrabile oggi rispetto a ciò che sarà durevole domani. Entrambe le cose sono legittime; non sono la stessa cosa.
Un sistema costruito su fondamenta in affitto segue l’orologio di chi le affitta. Quando la piattaforma sottostante cambia prezzi, interfacce o direzione, la roadmap cambia con essa, che il prodotto ne avesse bisogno o no.
Un sistema che si costruisce, si gestisce e si intende tenere segue un solo orologio: quello del problema. È più lento, ed è l’unico assetto in cui la risposta alla domanda «quando deve funzionare?» dipende dal problema e non da un calendario esterno.
Che cosa cambia nella pratica
La conseguenza non è che lavoriamo senza pressione. È che la pressione è tecnica anziché temporale.
Cambia ciò che possiamo permetterci di rifiutare. Una funzionalità che renderebbe una demo più impressionante e il sistema più difficile da comprendere può semplicemente essere scartata, perché nessuno all’esterno dell’azienda deve essere convinto questo mese.
Cambia il modo in cui ordiniamo il lavoro. L’ordine che ci siamo dati è la profondità prima dell’ampiezza: portare i sistemi attuali a maturità prima di aprire il fronte successivo. Quest’ordine è possibile solo per chi è proprietario. Un team che lavora secondo il calendario di qualcun altro è sotto una pressione continua ad annunciare la novità successiva, perché lì il progresso si misura in annunci.
Cambia il significato di un ritardo. Quando un problema si rivela più difficile del previsto, le opzioni sono risolverlo come si deve, risolverlo in parte oppure cambiare ciò che si era promesso. Con una scadenza esterna, la prima opzione spesso non è disponibile. Senza, di solito è quella giusta.
Cambia ciò che prendiamo in affitto. I servizi di base li affittiamo senza esitare, perché si possono sostituire senza toccare il prodotto. Ciò che definisce un prodotto no: i suoi dati, la sua logica centrale e la possibilità di spostarlo altrove restano nelle nostre mani.
L’indipendenza costa velocità. In cambio offre il diritto di essere pazienti, e la pazienza è l’unico modo per costruire qualcosa che continua a migliorare dopo un decennio.
Il costo, detto onestamente
Sarebbe disonesto presentare questo modello come migliore sotto ogni aspetto. È un compromesso, e il prezzo è reale.
Costruire e gestire i propri sistemi è più lento che assemblare sistemi in affitto. Entriamo in nuovi ambiti più lentamente, perché ciascuno deve arrivare a maturità prima che inizi il successivo. Alcune opportunità sfumeranno perché chiedevano una risposta prima che fossimo pronti a darne una buona, e alcune di queste saranno state perdite vere e non rinunce disciplinate. Chi sostiene che il proprio approccio non abbia alcuno svantaggio sta descrivendo una presentazione commerciale, non un’azienda.
Ciò che otteniamo in cambio è che lo standard di ingegneria non è negoziabile. Nella maggior parte delle aziende la qualità è la variabile che assorbe la pressione dei tempi, non per decisione, ma perché è l’unica variabile che conserva ancora un margine. Eliminare la scadenza esterna elimina quel meccanismo. Quando qui qualcosa non è abbastanza buono, la risposta è continuare a lavorarci, perché non c’è una scadenza con cui barattarlo.
Tenuto, non rivenduto
Ogni sistema che costruiamo è fatto per essere tenuto. Questa singola decisione spiega gran parte delle altre.
Se si intende vendere un prodotto entro tre anni, la strategia razionale è ottimizzare ciò che un acquirente potrà vedere fra tre anni. Se si intende tenerlo a tempo indeterminato, la strategia razionale è ottimizzare il costo di gestione al decimo anno. Ciò significa documentazione, confini, test e un’architettura scelta per persone che non sono ancora state assunte.
Queste due strategie producono codebase diverse fin dalla prima settimana. Noi abbiamo scelto la seconda, e la proprietà è ciò che ci permette di continuare a sceglierla quando il lavoro rallenta.