Secondo un recente studio, citato all’interno di questo articolo di The New Stack, oggi gli sviluppatori spendono meno del 25% del proprio tempo a sviluppare. Il che pare quasi un ossimoro: uno sviluppatore che non sviluppa. Come un muratore che passasse solo la prima metà della mattina a tirare in piedi una casa, ed il resto a fare “altro”.

Nello specifico poi questo “altro” che cosa è? Possiamo provare a rispondere per quanto riguarda gli sviluppatori. Se infatti in passato uno poteva definirsi solamente uno sviluppatore, questa cosa oggi è impossibile. Nel decennio che potremmo dire essersi appena concluso (diciamo dalla presentazione di Docker nel 2013) abbiamo visto fiorire la metodologia DevOps nella quale, pur con tutte le reticenze del caso, lo sviluppatore non è più estraneo a quanto avviene a livello di Operations, anzi, il più delle volte è egli stesso a gestire quella parte, magari occupandosi in prima persona di costruire gli ambienti (ad esempio i container) su cui far girare le applicazioni.

Ma è ancora sviluppo quello? E l’aspetto della sicurezza? Se è vero infatti che il decennio DevOps si è appena concluso ad esser partito è il nuovo periodo DevSecOps, in cui l’elemento sicurezza, l’approccio shift-left, non può più essere ignorato.

Si capisce quindi come il dato del 25% citato in apertura sia più che ponderato: 25% di Dev, 25% di Ops, 25% di Sec e, si spera, 25% tra progettazione e documentazione (lo so, sono un illuso).

Ma se uno volesse fare solamente lo sviluppatore sarebbe da criminalizzare?

Dice Brian Wald, CTO di GitLab, che interviene nell’articolo:

Integrating Dev, Ops and Sec was necessary to reduce the siloed teams, but doing so at the application-development level has introduced significant complexity. The ‘shift left’ movement correctly identified the need for earlier involvement in critical processes. But it also placed an unnecessary burden on engineers…

L’integrazione di Dev, Ops e Sec era necessaria per ridurre i team isolati, ma farlo a livello di sviluppo delle applicazioni ha introdotto una notevole complessità. Il movimento “shift left” ha correttamente identificato la necessità di un coinvolgimento precoce nei processi critici. Ma ha anche posto un inutile onere sugli ingegneri…

Ed in effetti è molto difficile dargli torto. Il punto è, come ne si esce?

Con l’automazione, ad esempio. Applicando il concetto di platform che sistemi come GitLab offrono. Lungi dall’usare i toni markettari dell’articolo, è una realtà inconfutabile quella che emerge dallo stato attuale delle cose. Essendo la complessità costantemente in crescita, esulare dalle automazioni sarebbe semplicemente folle.

Ma oltre alla parola CI (Continuous Integration) che fa capolino ogni volta che si parla con qualcuno di GitLab, c’è anche un altro acronimo di due lettere che secondo Wald salverà la vita degli sviluppatori, restituendo il tempo da dedicare agli sviluppi, ed ovviamente questo è l’Artificial Intelligence.

Questi agenti AI, secondo Wald, suggeriranno soluzioni, lasciando agli umani il compito di confermare e implementare la risoluzione, diminuendo il Tech Debt, scoprendo i problemi molto prima nella catena di produzione e migliorando in generale la gestione del tempo degli sviluppatori, che potranno tornare a fare (quasi) solo quello.

Troppo semplicistico?

Decisamente. La scorsa settimana parlavamo di bug scoperti dopo venticinque anni, ed era solamente agosto quando raccontavamo del peso che i Tech Debt ricoprono nelle strutture odierne. Si fa in fretta a capire come il cambiamento debba partire principalmente tra la tastiera e la sedia, prima ancora che nei tool.

Allora, e solo allora, l’AI sarà un valore aggiunto.