Case studies
What was decided, and why
7 analyses of real projects on systems that already had people working inside them. Each piece starts from the constraint that created the work, walks through the choices one by one including the rejected ones, and says what the client was left with.
Client names are omitted, the decisions are not
Analisi tecnica · software installato presso il cliente
Design
Quante versioni del tuo prodotto stai mantenendo davvero?
Ogni «sì, si può fare» detto in trattativa diventa un'installazione diversa da tenere in piedi per sempre. Le abbiamo contate, e poi abbiamo scoperto che i controlli che dovevano coprirle rispondevano verde da mesi senza guardare.
The constraint
Il prodotto è lo stesso ovunque. A rompersi è l'installazione, non l'applicazione, e nessuno sapeva quante installazioni diverse esistessero, perché non erano scritte da nessuna parte.
The outcome
Le configurazioni supportate sono diventate un elenco scritto, e «verde» ha smesso di significare tre cose diverse. Il lavoro ha rivelato controlli che dichiaravano successo senza aver verificato nulla e configurazioni senza alcun controllo. Il risultato consegnato è la mappa di dove sono i buchi, e quanto costa ogni riga.
Analisi tecnica · integrazione con un sistema di terzi
Design
Il fornitore non ha un'API. Il portale sì.
Come ho ricostruito il protocollo di un cloud industriale per portare i dati delle macchine dentro il gestionale del cliente, e perché mi sono fermato prima dell'ultimo endpoint.
The constraint
I dati esistevano, erano completi ed erano perfettamente visibili: su un portale del fornitore, dietro un login. Alla richiesta di un accesso programmatico il costruttore ha risposto allegando il manuale utente del portale.
The outcome
I dati arrivano nel gestionale senza più trascrizioni manuali, e l'integrazione gira ancora: il portale del costruttore è rimasto quello, perché è specifico per quelle macchine e cambiarlo costerebbe troppo. Lungo la strada è emerso che l'endpoint riordinava le risposte, e per due settimane i valori sono finiti nella colonna sbagliata senza produrre un solo errore.
Analisi tecnica · un dimostratore per una richiesta vera
Design
Tracking live dei mezzi su mappa
Come ho scelto lo scope, come ho ragionato architettura e test di una companion app .NET MAUI 9 nativa: dalla prima ipotesi al codice verificato.
The constraint
Chi sta in cantiere voleva vedere i mezzi sul telefono, non aprire il gestionale d'ufficio. Una richiesta legittima e vaga insieme: nessuno sapeva dire quanto grande fosse il lavoro, né se ne valesse la pena.
The outcome
Una feature portata end-to-end dallo stesso codice, con mappa nativa: eseguita e vista funzionare su iOS, compilata per Android. Ogni bivio è registrato con l'alternativa scartata, e la verifica è dichiarata per intero: cosa è coperto da test, cosa è stato provato a mano, cosa non è verificato e perché.
Case study · osservabilità di un sistema a eventi
Verify
Dalla cecità alla traccia: strumentare una pipeline esistente
Cosa costa aggiungere l'osservabilità a un sistema costruito senza pensarci: nove servizi, tre linguaggi, un broker in mezzo.
The outcome
Il percorso critico del dato è strumentato senza toccare la logica applicativa: agent e wrapper al posto del codice. Le tracce si sono rivelate già collegate attraverso i topic, quindi sei modifiche pianificate non sono state fatte, non rinviate: dimostrate non necessarie. Il resto del sistema è dichiarato fuori perimetro.
Analisi tecnica · autorizzazione di un sistema in esercizio
Design
Il permesso che il sistema non sapeva pronunciare
«Fa vedere il capitolato al subappaltatore, ma non farlo toccare.» Dieci parole che il sistema non aveva il vocabolario per dire. La storia di come si sostituisce l'autorizzazione di un sistema vivo senza migrare un solo record.
The outcome
L'autorizzazione per singola risorsa è diventata esprimibile in OpenFGA: da tre ruoli globali a un'ottantina di relazioni su sei tipi: senza migrare un solo record, e con la possibilità di ricostruire a posteriori chi vedeva cosa. Il percorso vecchio è stato rimosso dopo il periodo di doppia modalita': i permessi vecchi non erano dati, erano condizioni sparse nel codice. Il percorso precedente resta attivo dietro un flag, ed è la parte onesta del risultato.
Analisi tecnica · la consegna come problema di progettazione
Design
Software per chi non apre il terminale
L'algoritmo era la parte facile. A tenere in piedi la consegna hanno pensato SmartScreen, una casella in fondo a una schermata di installazione e una libreria da compilare: tutto ciò che sta fra il doppio click e il primo file ridotto.
The constraint
Sulla macchina di chi ha scritto il programma funzionava già tutto. Sul computer dell'utente non c'era né Python né il suo PATH, il sistema operativo trattava il launcher come una minaccia, e ogni errore reale arrivava in una lingua che il destinatario non parla.
Analisi tecnica · strumento di misura per lavoro in campo
Design
L'app che ho costruito stando fuori da Android
Venti progetti indipendenti, e la piattaforma che compare in uno solo. Come si rifà lo strumento di un tecnico che lavora su un traliccio, quando il sensore che misura non ce l'hai sulla scrivania.
The outcome
La parte che decide, cioè validazione della qualità del segnale, calibrazione, filtri, generazione del rapporto, si verifica senza telefono e senza sensore. Il codice legato alla piattaforma sta in due file su tutto il progetto. Restano scoperte l'integrazione dei venti pezzi e la prova contro il sensore vero.
Holding a similar situation?
Tell me how the system looks today and which decision you are stuck on. Half an hour to see whether there is a problem I can be useful on, no commitment.