L'app che ho costruito stando fuori da Android

Dieci minuti per salire

Un tecnico sale su un traliccio. Ci mette dieci minuti, e non è tempo che si recupera: scendere e risalire perché una misura non è stata registrata bene costa mezza mattinata. Lassù orienta un’antenna, legge l’inclinazione, aspetta che la posizione satellitare sia abbastanza buona da poter essere scritta in un documento, scatta le foto. La sera consegna un rapporto a un operatore mobile che quel rapporto lo pretende in un formato suo, diverso da quello dell’operatore del mese prima.

Lo strumento che regge tutto questo è un’applicazione su un telefono, collegata via rete a un sensore che fa le misure vere. Andava rifatta.

Il primo istinto

Si apre l’ambiente di sviluppo mobile, si crea il progetto, si comincia dalla prima schermata. È quello che fa chiunque, ed è difendibile: l’obiettivo è un’applicazione mobile, gli strumenti per farla sono quelli, e la prima schermata che compila è un segnale di avanzamento che si può mostrare a qualcuno.

Ho cominciato a farlo, e per un po’ è andata bene.

Quello che non puoi convocare

Poi arriva il momento in cui devi verificare qualcosa, e ti accorgi che ogni verifica interessante dipende da due cose che non hai.

Il sensore sta dal committente. Non è un dispositivo che si compra, si mette sulla scrivania e si accende quando serve: è lo strumento con cui qualcuno lavora, e quando lavora non è disponibile. Il traliccio, ovviamente, meno che mai.

E l’emulatore, dal canto suo, è lento. Non lento in senso assoluto, lento nel senso che conta: abbastanza da far sì che un controllo lo lanci alla fine, non mentre scrivi. Un ciclo di verifica che richiede trenta secondi si esegue dieci volte in un pomeriggio; uno che ne richiede tre lo esegui trecento.

Sommate, le due cose producono una situazione precisa: il progetto aveva un ciclo di verifica che dipendeva da qualcosa che non si poteva convocare. Non è un problema di strumenti, ed è per questo che comprare uno strumento migliore non lo risolve.

La domanda che ribalta il conto

La reazione naturale è chiedersi come si testa senza hardware. È una domanda ragionevole che porta in un vicolo, perché la risposta è sempre “si simula”, e simulare il sensore sposta il problema senza scioglierlo.

La domanda che scioglie è un’altra, ed è quasi imbarazzante nella sua semplicità: quanta parte di questa applicazione ha davvero bisogno della piattaforma?

La risposta, guardata con onestà, è quasi nessuna.

Il telefono ti dà una posizione. Decidere se quella posizione sia abbastanza buona per finire in un documento che qualcuno firma è un calcolo su una manciata di numeri. La calibrazione di un sensore è un’addizione con memoria. Un filtro sul segnale è aritmetica. Il rapporto finale è un documento costruito a partire da dati che hai già. Le regole di validazione che cambiano da un operatore all’altro sono un file di configurazione letto e applicato.

Niente di tutto questo ha bisogno di un telefono per esistere, e niente di tutto questo ha bisogno di un telefono per essere verificato. Ha bisogno di un telefono solo per essere usato, che è una cosa diversa e succede molto più tardi.

Venti progetti

Da lì la forma viene da sé. Venti progetti indipendenti, ognuno con il proprio file di build e il proprio ciclo di prova, e nessun progetto padre che li tenga insieme. Guida acustica, calibrazione, conversioni fra sistemi di coordinate, persistenza, invio dei messaggi, esportazione e importazione dei lavori, filtri sul segnale, posizione, misure, foto, profili di configurazione, rapporto, impostazioni, validazione, collegamento al sensore.

Nessuno dei venti dichiara la piattaforma mobile nel proprio file di build. In tutto il progetto, i file che importano qualcosa di specifico della piattaforma sono due, ed entrambi stanno nell’unico modulo che quella dipendenza la porta nel nome.

Il meccanismo che rende possibile la cosa è vecchio e non ha niente di ingegnoso: quello che la piattaforma fornisce entra da un’interfaccia. C’è chi emette il suono, e c’è chi decide quando emetterlo, con quale pausa e a quale distanza dal bersaglio. Sono due responsabilità diverse, vivono in due posti diversi, e solo la prima ha bisogno di un telefono. La seconda, che è quella dove stanno le decisioni e quindi dove stanno gli errori, si prova in millisecondi.

Il modulo che non parla col satellite

C’è un dettaglio che riassume tutto il resto, e la prima volta sembra un errore.

Il modulo che si occupa della posizione non contiene alcuna interfaccia di posizionamento. Non chiede la posizione al sistema operativo, non parla col satellite, non sa nemmeno da dove arrivi il dato. Contiene il campione, la lettura, la qualità, il validatore, e la macchina a stati dell’acquisizione.

Detto altrimenti: contiene tutto quello che serve a rispondere alla domanda questa misura è abbastanza buona da poterci scrivere sopra un rapporto?, e niente di quello che serve a ottenerla.

Sembra sbagliato finché non ti accorgi di quello che si rompe davvero. Il satellite funziona. A rompersi è la soglia scelta male, lo stato in cui l’acquisizione resta bloccata perché nessuno ha previsto quella combinazione, la misura accettata quando andava rifiutata e finita in un documento che qualcuno ha firmato. Sono tutti errori di logica, e la logica non ha bisogno di un cielo aperto per essere messa alla prova.

Un modulo che avesse incapsulato l’interfaccia di posizionamento avrebbe portato la piattaforma dentro il pezzo più denso di decisioni dell’intero progetto. Sarebbe stato il posto peggiore in cui metterla.

Il prezzo di venti build

Questa divisione costa, e vale la pena dire quanto prima che sembri gratis.

Venti progetti sono venti file di build da tenere allineati, venti insiemi di dipendenze che possono divergere, venti versioni che qualcuno deve far combaciare. Ogni volta che una libreria comune si aggiorna, il lavoro si moltiplica per venti invece che per uno.

E c’è un rischio peggiore del costo, perché il costo almeno si vede. Venti pezzi verificati singolarmente possono non funzionare insieme. La verifica di un modulo dice che quel modulo si comporta come previsto quando lo interroghi da solo; non dice niente su cosa succede quando venti moduli si passano dati in un ordine che nessuno ha provato per intero. L’integrazione resta lavoro vero, e non è raccontata qui perché non è ancora la parte finita.

Il conto quindi non è “questa divisione è gratis”, è: rende quasi gratuita la verifica di un pezzo, e trasferisce il rischio sull’integrazione. Conviene quando la maggior parte degli errori sta dentro i pezzi, e non conviene quando sta nelle giunture. Su un progetto pieno di soglie, calibrazioni, validazioni e formati di rapporto, sta dentro i pezzi.

Cosa cambia per chi paga

Il cambiamento che conta non è tecnico e non è nel numero dei moduli.

È che si può lavorare al progetto senza avere lo strumento. Chi scrive la logica di validazione non deve prenotare il sensore, non deve aspettare che un tecnico scenda dal traliccio, non deve accendere un emulatore per sapere se una soglia è giusta. Un pezzo del lavoro ha smesso di dipendere dalla disponibilità di qualcosa che non si controlla, ed è la specie di dipendenza che non compare in nessun preventivo perché non si scrive come una voce di costo: si presenta come un’attesa.

E c’è un secondo effetto, che si vede più tardi. Il giorno in cui quella logica dovrà girare da qualche altra parte, su un’altra piattaforma o dentro un servizio che elabora i rapporti prima che arrivino all’operatore, la parte da riscrivere sono due file. Non era l’obiettivo, e prometterlo sarebbe stato disonesto. È quello che succede quando smetti di scrivere aritmetica dentro un telefono.