Nei prossimi mesi pubblicheremo, nella nostra collana MBook disponibile in download dal sito, un libro dedicato a un interessante parallelismo tra architettura dello sviluppo del software e temi filosofici. Nella storia del pensiero umano, infatti, certi problemi e certi interrogativi tornano a più riprese. Ma anche nel mondo dello sviluppo software ci si interroga da tempo su come affrontare e risolvere determinati problemi. Su questa metafora, e sul modo in cui certi problemi affrontati nella storia della filosofia possano ritrovarsi nello sviluppo contemporaneo di architetture software, si basa appunto il nuovo libro di Alberto Acerbis. In questo articolo, l’autore ci introduce alla questione e presenta alcuni spunti di riflessione.

———————————————————————

Il problema non è mai stato il codice

Negli ultimi tempi mi sono ritrovato a mettere in discussione una convinzione che avevo dato per scontata per molti anni: che il mio lavoro fosse costruire software. È una frase che sembra perfettamente ragionevole. Dopotutto faccio il software architect. Passo le giornate a discutere di sistemi distribuiti, Domain-Driven Design, cloud, architetture event-driven, AI e microservizi. È naturale pensare che il software sia il centro del mio lavoro.

Eppure, più passa il tempo, più mi convinco che il software arrivi sempre per ultimo. Il software è il risultato. Non è il punto di partenza.

Scrivere codice non basta

Negli ultimi vent’anni il nostro settore è cambiato radicalmente. Sono cambiati i linguaggi, i framework, il modo di distribuire le applicazioni. Abbiamo imparato a costruire sistemi distribuiti, a utilizzare il cloud, a orchestrare container e a progettare architetture basate sugli eventi.

Oggi, grazie all’intelligenza artificiale generativa, possiamo perfino delegare una parte significativa della scrittura del codice. Se guardassimo soltanto gli strumenti, dovremmo concludere che sviluppare software non è mai stato così semplice.

E allora perché continuiamo a costruire sistemi che, dopo pochi anni, diventano difficili da comprendere? Perché continuiamo a riscrivere applicazioni che, dal punto di vista tecnologico, funzionano ancora perfettamente? Perché le discussioni più lunghe di un progetto raramente riguardano il framework, il database o il linguaggio di programmazione?

La mia esperienza è che le conversazioni davvero importanti iniziano molto prima. Cominciano quando qualcuno pronuncia una frase apparentemente banale: “Vorrei un sistema per gestire gli ordini.”

Interrogarsi, proprio come in filosofia…

Da quel momento inizia il vero lavoro.

• Che cos’è esattamente un ordine?
• Quando nasce?
• Quando smette di esistere?
• Può essere modificato?
• Chi ne è responsabile?

Due persone possono utilizzare la stessa parola attribuendole significati completamente diversi, spesso senza nemmeno accorgersene. Ed è proprio lì che nasce la complessità. Non nel codice. Nel significato.

Negli ultimi mesi questa sensazione è diventata ancora più forte. L’arrivo dell’AI generativa ha alimentato una domanda che tutti, almeno una volta, ci siamo posti: “Se una macchina può scrivere il codice, quale sarà il ruolo di uno sviluppatore? E di un software architect?”

Comprendere i problemi

Non ho una risposta definitiva. Ma ho una convinzione sempre più forte: l’intelligenza artificiale non ha reso meno importante il nostro lavoro. Ha semplicemente messo in evidenza la parte del nostro lavoro che è sempre stata fondamentale: comprendere il problema.

Perché quando il contesto è ambiguo, anche il codice generato dall’AI sarà ambiguo. Quando il dominio è compreso male, anche la soluzione più elegante poggerà su fondamenta fragili. L’AI ha reso il codice più economico. Non ha reso più economica la comprensione.

Forse le domande che ci poniamo ogni giorno sono molto più antiche di quanto immaginiamo. Quando decidiamo che cosa rappresentare in un sistema, stiamo scegliendo quali aspetti della realtà considerare importanti. Quando definiamo un modello, stiamo stabilendo quali differenze meritano di esistere e quali possono essere ignorate. Quando assegniamo un nome a qualcosa, non ci limitiamo a descriverla. Le parole influenzano il modo in cui le persone la comprenderanno, ne parleranno e costruiranno software attorno a essa.

Il risvolto della filosofia

Queste non sono soltanto decisioni tecniche. Sono decisioni sulla realtà, sulla conoscenza e sul significato. Ed è forse per questo che le tecnologie cambiano continuamente, mentre alcune difficoltà rimangono sempre le stesse.

Possiamo sostituire un framework. Possiamo migrare un database. Possiamo riscrivere un’applicazione. Possiamo persino chiedere a un’intelligenza artificiale di generare il codice. Ma nessuno strumento può decidere al posto nostro che cosa il sistema debba davvero rappresentare.

Il codice può essere automatizzato. La comprensione no.

Ed è lì, molto prima della prima riga di codice, che comincia davvero l’architettura.