Ne stavo parlando con il mio amico Jan, e lui mi ha fatto notare alcuni aspetti che mi erano sfuggiti. Ma prima di arrivare al punto, mettiamo i pensieri in ordine.
Negli ultimi decenni il codice è stato una risorsa scarsa — come ho già scritto in un altro post — e attorno a questa scarsità l’industria del software ha costruito un intero castello di carte. Per esempio, la struttura dei software commerciali è generica, con possibilità di personalizzazione più o meno marcata: dalle semplici impostazioni fino a vere e proprie capacità di customizzazione avanzata. Sono stati persino sviluppati linguaggi interni alle applicazioni, più o meno visuali, per scrivere e implementare funzionalità specifiche per gli utenti finali: i cosiddetti DSL (Domain Specific Language).
La logica, insomma, è stata questa: scrivere un’applicazione con un linguaggio di programmazione generalista — C++, C#, Java e simili — costa molto, quindi meglio creare applicazioni generiche, facilmente modificabili in una direzione precisa e con confini precisi, e dotarle di linguaggi dalla sintassi limitata a questo unico scopo.
La creazione di queste capacità di customizzazione avanzata ha generato di conseguenza un intero mercato di aziende di consulenza, capaci di destreggiarsi in queste personalizzazioni per aiutare i clienti a prendere un’applicazione generica e aggiungerle la parte mancante. In pratica, la conoscenza si divide così: un software generico, pensato per un particolare scopo, che detta le linee guida del problema; la conoscenza che il cliente finale ha del proprio problema e del proprio contesto; e un consulente nel mezzo, che cerca di unire le due cose.
Le implicazioni di questo modello sono molteplici, e più o meno tutti abbiamo esperienza di casi di successo e di insuccesso. Ma a parte questo, vorrei far emergere un aspetto non scontato: la manutenzione del software. Più le funzionalità crescono e più clienti usano il software, più la manutenzione diventa difficile, fino a rendere quasi impossibile l’aggiunta di nuove funzionalità. Ogni modifica rischia infatti di rompere una customizzazione aggiunta da un cliente, di cui il produttore non è necessariamente a conoscenza. Come fa una software house a modificare o aggiornare il proprio prodotto senza rompere personalizzazioni che non conosce? Il risultato è che le software house devono chiedere sempre più soldi per aggiungere al software generico funzionalità che il cliente finale non ha richiesto, e che a ogni release rischiano di danneggiarlo. Il cliente lo sa bene: ogni aggiornamento che non incorpora qualcosa che gli serve può solo rompere un software che per lui funziona.
Bene, questo è lo stato attuale. Ma chi è arrivato fin qui sa già dove voglio andare a parare: cosa succede a questo modello quando il costo del codice tende a zero?
C’è chi obietta che il costo vero del software non è mai stato il codice, ma capire cosa costruire, verificarlo, mantenerlo. Vero. Ma io lavoro in una enterprise e i numeri li vedo ogni giorno: quello che prima facevano cinquanta persone, oggi lo fa una. E non è un numero buttato lì. Il punto è che il castello di carte non è fatto di “costo del software” in astratto: è fatto di fatturati proporzionali al numero di persone. Body rental, consulenza a tariffa giornaliera, team venduti a peso. Se il collo di bottiglia si sposta da “scrivere codice” a “sapere cosa chiedere e verificare di averlo ottenuto”, resta comunque un collo di bottiglia da una persona, non da cinquanta. E su un collo di bottiglia da una persona non ci costruisci una società di consulenza da migliaia di dipendenti.
Qualcuno dirà che quando il software costa meno il mondo ne chiede di più — gli economisti lo chiamano paradosso di Jevons — e quindi il lavoro non sparirà. Può darsi. Ma anche in quel caso il lavoro avrà una forma completamente diversa, e la struttura che vende teste muore lo stesso. Il castello di carte cade, quindi. Ma in un modo forse non così scontato.
Il cliente finale potrebbe in teoria crearsi in casa un software totalmente custom, ma si esporrebbe a due problemi. Il primo: il suo business non è fare software, quindi mettersi a fare un lavoro diverso dal proprio è un controsenso a livello di business. Il secondo: la conoscenza completa del software che sta usando è distribuita tra tre attori — software house, system integrator e cliente. Il cliente, da solo, è come uno sgabello a tre gambe a cui ne mancano due.
E non è solo teoria: qualcuno l’esperimento l’ha già fatto, e con soldi praticamente illimitati. Le banche. Si sono comprate intere software house e le hanno messe a fare software per loro. Il risultato? Software vecchi e inefficienti, e centinaia di persone da pagare. C’è una frase attribuita a Henry Ford: se avessi seguito le richieste dei clienti, avrei costruito un super cavallo invece di un’automobile. Le banche hanno digitalizzato i processi che già avevano invece di reimmaginarli: sono piene di super cavalli zoppi, e di automobili non se ne vedono. Si sono scavate la fossa da sole; non è ancora evidente solo perché queste cose richiedono tempo, e nel frattempo i soldi per coprire il problema li hanno. E attenzione: il loro fallimento non era un problema di costo del codice, ma di pensiero. Il che significa che il codice a costo zero non salverà nessuno da questo errore — permetterà solo di costruire il proprio disastro più in fretta e spendendo meno. Il super cavallo zoppo del 2030 sarà generato, non scritto.
La vera domanda, quindi, è: come si comporteranno questi tre attori in presenza dell’AI? Certo, esistono casi in cui, date le scarsissime personalizzazioni necessarie, gli attori in gioco sono solo due — software house e cliente — ma anche lì gli scenari sono piuttosto interessanti. Per un attimo, però, mettiamoli da parte.
Il cliente penserà: perfetto, posso svilupparmi il software da solo e preoccuparmi della manutenzione solo quando mi serve, o comunque ridurla in modo significativo. In pratica, una versione colossale del foglio di Excel. E qui devo confessare che dopo trent’anni nel mondo del software una risposta sul bilancio di Excel ce l’ho, e non è tenera: Excel ha risolto piccoli problemi e ne ha generati di enormi. Ho perso il conto delle volte in cui mi è stato chiesto di “convertire questo foglio di Excel in un software”. Dietro quella richiesta non c’è quasi mai un’esigenza nuova: c’è il tentativo di nascondere un grosso fallimento — il fallimento di non aver capito dove erano i propri limiti. Lo so, tutti abbiamo quel foglio di Excel a cui siamo affezionati e che ci è stato utile, ma è solo la nostra visione personale. E so che su questo punto mi attirerò parecchie antipatie, ma è proprio su questo aspetto della natura umana che poggia gran parte del ragionamento di questo articolo.
C’è però una differenza cruciale tra il vecchio Excel e quello che sta arrivando. Chi scrive un foglio di Excel, nel bene e nel male, capisce le formule che ha scritto: il suo fallimento è organizzativo, una crescita senza controllo. Chi invece si genera un software con l’AI rischia di non capire nemmeno il sistema che sta usando. Il nuovo Excel eredita il vizio del vecchio e ne aggiunge uno peggiore: l’opacità totale dell’artefatto.
Le software house, dal canto loro, iniziano a pensare: bene, potremo ridurre i costi e guadagnare di più. Se la customizzazione la fa l’AI, non avremo neanche più bisogno dei system integrator, e potremo azzerare i lunghi tempi di adozione del software. Ma anche in questo caso la sfida è grande, perché tutta quella conoscenza «ponte» — tra una software house abituata a ragionare in modo generico e ad alto livello e i problemi specifici dei clienti — non è facile da colmare. Inoltre, quando qualcosa diventa abbondante si formano parecchie distorsioni. Ricordo ancora quando, all’inizio degli anni 2000, costruire un sito web è diventato alla portata di tutti: il risultato è stato che la pagina fatta da un amico o da un parente era diventata indistinguibile da quella di un grande e-commerce (ok, ai tempi Amazon non era ancora quella che conosciamo oggi, ma è per farmi capire). E quel problema, a più di vent’anni di distanza, non è ancora risolto.
I system integrator, da parte loro, inizieranno a pensare di poter fare a meno delle software house. Ma anche in questo caso — che in teoria sembra forse il più fattibile — la pratica è molto diversa. Non entro nei dettagli per non appesantire l’articolo, ma le considerazioni non si discostano molto dalle precedenti. Direi che siamo in una via di mezzo.
Penso che ci saranno sicuramente casi di successo di clienti che riusciranno a fare da soli — d’altra parte esiste pur sempre qualche foglio di Excel di successo — e lo stesso varrà per gli altri due attori. E ci saranno disastri: so di essere facile profeta nel dirlo, ma è il prezzo da pagare per ogni grande cambiamento. Forse però la profezia non è il punto. Il punto è che il codice smetterà di essere la risorsa scarsa attorno a cui questo mondo si è organizzato. E allora la domanda vera è un’altra: qual è la nuova scarsità? E chi, dei tre attori, è posizionato per possederla?
Grazie Jan Morath per ispirarmi sempre
Leave a Reply