La stampa 3D e lo sviluppo software sembrano attività molto diverse.

Da una parte ci sono plastica, motori, temperature, tolleranze e oggetti che possono staccarsi dal piano alle tre di notte. Dall'altra file, funzioni, database e applicazioni che possono smettere di funzionare alle tre di notte.

Riflettendoci, la differenza principale è che con la stampa 3D il fallimento rimane fisicamente sul tavolo.

Puoi prenderlo in mano, osservarlo e conservarlo in una scatola insieme agli altri errori. Nel software, invece, spesso premi “annulla”, correggi il codice e provi a non raccontare a nessuno ciò che è successo.

Lavorare per anni tra modellazione, prototipazione e fabbricazione digitale ha cambiato il mio modo di progettare software.

Mi ha insegnato che un modello perfetto sullo schermo non è necessariamente un buon oggetto. E, allo stesso modo, un'applicazione elegante nel codice non è necessariamente un buon sistema.

Il progetto incontra sempre la realtà

Un modello 3D può essere geometricamente corretto e impossibile da produrre.

Una parete è troppo sottile. Un foro non considera la tolleranza. Due parti coincidono esattamente, quindi non si monteranno mai. Un supporto funziona nell'orientamento ideale ma richiede una quantità assurda di materiale durante la stampa.

Il software possiede equivalenti molto simili.

Una funzione è corretta, ma l'utente non capisce come usarla. Un flusso funziona con dati perfetti, ma i dati reali non lo sono mai. Un sistema regge dieci elementi e diventa inutilizzabile con diecimila. Due servizi rispettano formalmente il contratto, ma interpretano diversamente lo stesso stato.

Il progetto non termina quando la soluzione è logicamente valida.

Termina quando incontra condizioni reali e continua a funzionare.

Le tolleranze non sono errori

Nella modellazione meccanica, due parti che devono accoppiarsi non vengono sempre disegnate con le stesse dimensioni nominali.

Serve un gioco. Quanto dipende dal materiale, dalla macchina, dal processo e dal tipo di movimento richiesto.

All'inizio questa cosa può sembrare una concessione all'imprecisione. In realtà è progettazione della realtà.

Anche il software ha bisogno di tolleranze.

Una persona inserirà un testo più lungo del previsto. Una rete sarà lenta. Un servizio esterno risponderà in ritardo. Un file conterrà un carattere insolito. Un dato obbligatorio mancherà proprio nel record più importante.

Progettare soltanto per il caso ideale equivale a disegnare un incastro perfetto ignorando che verrà prodotto da una macchina reale con un materiale reale.

La robustezza nasce dallo spazio lasciato all'imperfezione.

Il primo prototipo deve rispondere a una domanda

Un prototipo non serve a dimostrare che il progetto è finito in piccolo.

Serve a verificare un'ipotesi.

La forma entra nello spazio disponibile? Il meccanismo si muove? L'impugnatura è comoda? Le parti possono essere montate? Il materiale reagisce come previsto?

Se un prototipo cerca di verificare tutto contemporaneamente, diventa costoso e difficile da leggere. Quando fallisce non sappiamo quale ipotesi fosse sbagliata.

Lo stesso vale per il software.

Una prima versione dovrebbe rispondere alle domande più rischiose:

  • il flusso è comprensibile?
  • i dati necessari esistono davvero?
  • l'integrazione è possibile?
  • la funzione principale produce valore?
  • il sistema regge il volume previsto?

Costruire subito ogni dettaglio significa investire molto prima di sapere se le fondamenta sono corrette.

Il prototipo migliore non è quello che assomiglia di più al prodotto finale. È quello che riduce più rapidamente l'incertezza.

Vedere l'errore cambia il modo di lavorare

Una stampa fallita è esplicita.

Gli strati si separano, la geometria si deforma, il supporto cede, la superficie racconta ciò che è successo. L'errore lascia tracce.

Questo porta naturalmente a osservare il processo, non soltanto il risultato.

Temperature, velocità, orientamento, materiale e geometria partecipano allo stesso fallimento. Raramente la soluzione consiste nel cambiare un singolo valore a caso e sperare.

Nel software cerco lo stesso tipo di visibilità.

Log, controlli, messaggi di errore e metriche sono il corrispettivo delle tracce sulla stampa. Un sistema che dice soltanto “qualcosa è andato storto” è un oggetto fallito gettato via prima di essere osservato.

Se non posso capire dove e perché il processo si è interrotto, non posso migliorarlo. Posso soltanto ripeterlo con crescente superstizione.

L'orientamento modifica il risultato

Lo stesso modello stampato in orientamenti diversi può produrre oggetti molto differenti.

Cambiano resistenza, qualità superficiale, supporti, tempi e quantità di materiale. Non esiste sempre un orientamento perfetto: si sceglie quale caratteristica privilegiare.

Nel software le decisioni architetturali funzionano allo stesso modo.

Centralizzare un dato semplifica la coerenza ma aumenta la dipendenza dalla sorgente. Calcolare un risultato in tempo reale lo mantiene aggiornato ma può rallentare il sistema. Memorizzarlo migliora le prestazioni ma introduce il problema dell'invalidazione.

Ogni scelta ottimizza qualcosa e presenta un costo altrove.

Chiedere “qual è la soluzione migliore?” senza specificare il requisito equivale a chiedere quale sia il miglior orientamento di stampa senza mostrare l'oggetto.

I supporti servono, ma poi vanno rimossi

Durante la stampa alcune geometrie hanno bisogno di strutture temporanee.

I supporti permettono di costruire parti che altrimenti non potrebbero essere depositate. Sono indispensabili durante il processo, ma non appartengono all'oggetto finale.

Anche nello sviluppo usiamo supporti temporanei:

  • dati fittizi;
  • script di migrazione;
  • interfacce provvisorie;
  • compatibilità con vecchi formati;
  • strumenti diagnostici;
  • procedure manuali durante una transizione.

Il problema nasce quando ciò che doveva essere temporaneo diventa parte permanente del sistema.

Una soluzione provvisoria mantenuta per anni accumula dipendenze. Nessuno sa più se possa essere rimossa e ogni nuova funzione comincia ad appoggiarsi anche a quella.

Nel mondo fisico riconosciamo immediatamente un supporto rimasto attaccato all'oggetto. Nel software può sembrare architettura.

Serve quindi progettare anche la rimozione: quando il supporto non sarà più necessario, come lo elimineremo senza danneggiare il resto?

Progettare per il processo, non soltanto per la forma

Un oggetto destinato alla stampa 3D dovrebbe essere pensato considerando il processo con cui verrà prodotto.

Questo non significa lasciare che la macchina decida la forma. Significa conoscere vincoli e opportunità della tecnologia.

Nel software accade lo stesso.

Un'interfaccia non può essere progettata ignorando i dati disponibili. Un backend non può essere costruito senza capire chi inserirà i contenuti. Un'integrazione non può dare per scontato che il sistema esterno sia sempre raggiungibile.

Design e implementazione non sono fasi indipendenti che si passano il lavoro attraverso un documento.

Sono prospettive diverse sullo stesso oggetto.

Quando conosco il processo posso usarlo come parte del progetto, invece di subirlo alla fine.

La precisione utile

La modellazione 3D permette di lavorare con precisioni enormi.

Questo non significa che ogni dettaglio debba essere definito con tutte le cifre disponibili. La precisione necessaria dipende dal processo e dalla funzione.

Progettare una quota al millesimo di millimetro per una macchina e un materiale che non possono riprodurla non rende il progetto più accurato. Rende più elegante il numero sullo schermo.

Nel software possiamo costruire sistemi estremamente generici, configurabili e astratti per problemi che richiedono una soluzione piccola e stabile.

La complessità può sembrare precisione intellettuale. Ma se non produce un beneficio concreto è soltanto materiale aggiunto.

La soluzione corretta possiede la precisione richiesta, non quella massima teoricamente raggiungibile.

Iterare non significa improvvisare

La prototipazione procede per iterazioni.

Si costruisce, si misura, si osserva e si modifica. Ma ogni iterazione dovrebbe incorporare ciò che abbiamo imparato.

Cambiare continuamente direzione senza registrare risultati non è prototipazione. È indecisione con una stampante accesa.

Anche nello sviluppo agile la velocità non dovrebbe eliminare la memoria.

Servono decisioni documentate, test, versionamento e criteri per capire se una modifica migliora davvero il sistema.

Iterare bene significa rendere economico l'apprendimento, non rendere infinita la revisione.

Ogni oggetto porta con sé il proprio processo

Quando guardiamo un oggetto finito, il processo scompare.

Non vediamo i prototipi falliti, le tolleranze corrette, le prove di orientamento e le modifiche necessarie per produrlo.

Quando usiamo un buon software accade la stessa cosa.

Non vediamo la gestione degli errori, le migrazioni, i controlli sui dati e le decisioni architetturali. Vediamo un'interfaccia che risponde e un'operazione che si conclude.

La semplicità del risultato è spesso prodotta da una grande attenzione al processo.

La stampa 3D mi ha insegnato soprattutto questo: progettare non significa descrivere perfettamente una forma ideale.

Significa accompagnare un'idea attraverso materiali, strumenti, limiti, errori e persone finché diventa qualcosa che può esistere davvero.

Che si tratti di una scocca in plastica o di un'applicazione web, il lavoro comincia sullo schermo.

Ma il progetto viene giudicato altrove.