L'industria dello sviluppo software sta cambiando — permanentemente

Nel 2003 ho fondato DCSL Software, che in seguito è diventata One Beyond. Sono uscito nel 2023 dopo aver portato l'azienda a livello internazionale e averla fatta crescere fino a oltre 300 persone. Da allora, ho fondato una start-up di robotica e raccolto oltre 4 milioni di sterline in finanziamenti seed.

Non mi sarei mai aspettato di scrivere di nuovo software di produzione. Ho smesso di programmare quotidianamente nel 2014, non perché non potessi farlo, ma perché è quello che succede quando un'azienda si espande. Assumi persone migliori di te nell'esecuzione, ti concentri sulla leadership e gradualmente la tastiera si allontana sempre di più. Per quasi un decennio, questo mi è sembrato del tutto naturale.

Quello che non mi aspettavo era che, quasi dieci anni dopo, mi sarei ritrovato di nuovo al posto dello sviluppatore — non nostalgicamente, ma praticamente. Non dilettandomi ma costruendo una piattaforma di robotica genuinamente complessa. E non reimparando ogni framework o linguaggio che mi era passato accanto, ma lavorando in un modo fondamentalmente diverso.

Questo cambiamento personale è il segnale più chiaro che ho visto che qualcosa di strutturale è cambiato nello sviluppo software.

Come progettavamo il software — e perché

Quando ho iniziato, eravamo fermamente nell'era waterfall. Non era ideologia, era economia. Il software era lento e costoso da costruire, quindi l'unico approccio sensato era pensare molto attentamente in anticipo.

Scrivevamo specifiche dettagliate perché dovevamo farlo. I contratti dipendevano da esse. La consegna dipendeva da esse. Scrivere una buona specifica era una competenza specialistica, e io ero ragionevolmente bravo in questo. Potevo visualizzare come sarebbe stato il prodotto finito prima che esistesse, prevedere aree di complessità e descrivere il comportamento con sufficiente precisione affinché un team potesse costruirci sopra.

Quella capacità era rara e difficile da insegnare. Molte persone avevano difficoltà perché immaginare un sistema complesso che non esiste ancora è genuinamente difficile. Ma era importante, perché sbagliare le cose in ritardo nel processo era doloroso e costoso.

Nel tempo, l'industria si è orientata verso Agile. Pubblicamente, questo è stato presentato come un modo migliore per rispondere al cambiamento. Silenziosamente, era anche un riconoscimento che per sistemi grandi e di lunga durata, nessuna specifica sopravvive intatta. Le aziende cambiano, gli utenti cambiano, la tecnologia cambia, e fingere il contrario spesso causava più danni che benefici.

Agile era pragmatico, ma aveva un costo. Abbiamo largamente abbandonato la progettazione approfondita iniziale e l'abbiamo sostituita con la scoperta incrementale. Questo funzionava, ma normalizzava anche una mentalità in cui pensare troppo avanti era visto come non necessario o persino rischioso.

Cosa è cambiato — e perché ho ricominciato a costruire

Il motivo per cui sono stato in grado di tornare allo sviluppo pratico non è che improvvisamente ho trovato il tempo o il desiderio di reimparare dieci anni di strumenti. È perché l'IA ha cambiato fondamentalmente il costo della sperimentazione.

Questa è la parte che spesso viene fraintesa. Il vero cambiamento non è che il codice è più veloce da scrivere. È che provare le cose è ora economico, veloce e ampiamente reversibile.

Cose che una volta avrebbero richiesto settimane di sviluppo possono ora essere tentate in pochi minuti. Puoi esplorare un approccio, vedere come si sente, scartarlo completamente e provare una direzione diversa con pochissima penalità. Questo semplicemente non era possibile prima.

In passato, c'era un forte attaccamento emotivo e finanziario al codice. Se qualcosa richiedeva a due sviluppatori tre settimane per costruirla, eri comprensibilmente riluttante a buttarla via. Le decisioni si consolidavano presto, non sempre perché erano giuste, ma perché invertirle era troppo costoso.

Quel vincolo è sparito ed è questo che mi ha riportato dentro. Ora posso operare al livello in cui sono più forte — comprendere il problema, modellare il sistema, individuare quando la complessità sta aumentando — mentre l'IA gestisce la meccanica. Non sto scrivendo codice come facevo a vent'anni. Lo sto dirigendo, perfezionando, correggendo e occasionalmente fermandolo dall'andare nella direzione completamente sbagliata. In pratica, questo assomiglia molto di più alla guida di un team che alla scrittura di codice. Sei effettivamente il capo — stabilisci la direzione, rivedi l'output, individui scorciatoie pigre e resisti quando qualcosa non sembra giusto.

Perché il design conta ancora — più che mai

Sarebbe facile presumere che questa nuova libertà renda il design meno importante. In realtà, lo rende più importante.

Avere un'idea chiara e dettagliata di ciò che stai cercando di costruire è ancora estremamente prezioso. In effetti, migliora attivamente l'output dell'IA. Più chiaro è l'intento, migliori sono i risultati. Un pensiero vago produce semplicemente sistemi vaghi più rapidamente. Ciò che è importante capire è che l'IA si comporta molto come una persona. Vuole essere utile. Vuole darti una risposta. Se sei vago, riempirà le lacune. Se sei disattento, farà supposizioni. Se non la metti in discussione, continuerà con sicurezza lungo la strada sbagliata.

La differenza è che il design non è più un artefatto fragile e una tantum che deve sopravvivere immutato per anni. È diventato una guida per la sperimentazione piuttosto che un vincolo su di essa. Puoi mantenere una visione forte di dove stai andando pur essendo disposto a provare, scartare ed evolvere il percorso che ti ci porta.

La nuova competenza è sapere quando l'esplorazione è produttiva e quando è solo rumore. L'IA continuerà felicemente a generare struttura molto tempo dopo che avrebbe dovuto essere semplificata. Non sa quando un file è diventato troppo grande, quando un'astrazione sta cedendo o quando qualcosa che "funziona" oggi causerà problemi in seguito. Quegli istinti provengono ancora dall'esperienza.

Cosa rompe questo nell'industria

Una volta che la sperimentazione diventa economica, molte ipotesi consolidate smettono di reggere. La pianificazione non riguarda più il bloccare tutto in anticipo. Riguarda la definizione di intenti, vincoli e confini.

La stima diventa meno una questione di previsione dello sforzo e più una questione di comprensione dello spazio che stai esplorando.

E la nostra relazione con il codice cambia completamente. C'è molto meno attaccamento a implementazioni specifiche e molta più attenzione su comportamento, struttura e risultati.

Questo è il motivo per cui l'industria dello sviluppo software si sente inquieta. Molte persone stanno cercando di applicare vecchi modelli mentali a nuovi strumenti. Questo funziona per un po', ma perde il punto.

Il vero cambiamento

Il motivo per cui sono fiducioso che questo cambiamento sia permanente è semplice: non starei costruendo di nuovo altrimenti.

L'unica ragione per cui posso credibilmente tornare allo sviluppo pratico dopo un decennio di assenza è che i vincoli che mi avevano spinto fuori in primo luogo non si applicano più. Il software può ora evolversi attraverso la sperimentazione guidata in un modo che semplicemente non era possibile prima.

Questo non significa che l'esperienza conti meno. Significa che conta in modo diverso. Il valore non è più nel ricordare sintassi o framework. È nel giudizio, nella struttura e nel sapere quando fermarsi.

Questa non è la fine dello sviluppo software. Ma è la fine del vecchio modello. E una volta che hai lavorato in questo modo, non si torna indietro.