“Da gamer, non aspetto altro. Come sviluppatrice, invece, non vorrei mai lavorare sulla retrocompatibilità. È un lavoro di manutenzione devastante!".
– Una sviluppatrice del nostro team che vuole rimanere anonima! Chiamiamola Dev-I.
La scorsa settimana stavo parlando di retrocompatibilità con gli sviluppatori interni di Appian quando una di loro ha detto questa frase. Da appassionata giocatrice e fan di Nintendo, ha anche condiviso l'immagine della retrocompatibilità di Nintendo (grazie all'utente reddit u/rushiosan) e ha insistito che la menzionassi nel blog. Insomma, ecco a voi Dev-I.
Il pensiero di Dev-I non è una novità.
Molti sviluppatori non sopportano di dover fare manutenzione del software perché è un lavoro noioso.
Per me, è come avere le capacità per costruire e inviare un razzo su Marte, ma passare la maggior parte del tempo a fare manutenzione su un razzo degli anni '90 che potrebbe non volare mai più (è l'ingegnere aerospaziale in me che parla!)
Ma perché la manutenzione è tanto disprezzata? La risposta sta da qualche parte tra 306 milioni di ore, il calo di produttività e il mancato riconoscimento del proprio lavoro.
Questo post offre due diverse prospettive: quella della nostra misteriosa Dev-I che non sopporta le opere di manutenzione come la retrocompatibilità e quella del nostro Responsabile di prodotto che cerca di semplificare la vita a questi sviluppatori.
Il lavoro di manutenzione richiede troppo tempo
In media, gli sviluppatori come Dev-I spendono 17 ore a settimana in opere di manutenzione. Con 18 milioni di sviluppatori in tutto il mondo, si ha un totale di *controlla la calcolatrice* 306 milioni di ore impiegate ogni settimana per la manutenzione globale.
Trecentosei milioni di ore. Su cose come refactoring del codice, estensioni, migrazioni... e retrocompatibilità.
Nessuno mette in discussione l'importanza della manutenzione. Ma, come dice questo articolo di uselessdevblog, la scelta è sempre tra fornire valore o fornire manutenzione.
Meno ci si concentra sulla manutenzione, più si accumula debito tecnico. Le aziende lo capiscono, ma spesso non investono abbastanza tempo o denaro in opere di manutenzione. Perché fare business consiste nel creare valore, giusto?
“Il mio datore di lavoro mi paga per concentrarmi sul fornire valore. Ma così si rischia di incorrere nel debito tecnico. E non ci sono incentivi a pagare qualcuno per affrontarlo” - uselessdev
La manutenzione non è mai il motivo principale per cui si fa questo mestiere. Gli sviluppatori come Dev-I non hanno imparato a programmare con il sogno di fare manutenzione del codice.
Retrocompatibilità: gratificante per alcuni, ripetitiva per altri
Alcune opere di manutenzione - come la retrocompatibilità - possono anche risultare gratificanti.
Basta chiedere al team responsabile della retrocompatibilità di Xbox. La nuova Xbox Series X è compatibile con quattro generazioni precedenti di Xbox, per la gioia dei giocatori di tutto il mondo (a meno di non essere fan di Nintendo come Dev-I).
Mettete un qualunque vecchio gioco per Xbox nella nuova console, dite un paio di preghiere (facoltative), fatevi venire gli occhi lucidi per la nostalgia e iniziate a giocare. Niente di più semplice.
Così si fornisce un'esperienza cliente in grado di cambiare le carte in tavola, entusiasmando milioni di utenti Xbox in tutto il mondo. Insomma, si tratta di un tipo di manutenzione che offre un riconoscimento diretto agli sviluppatori.
Ma la retrocompatibilità non è sempre così gratificante o interessante, specialmente nel mondo del software low-code di Dev-I.
Retrocompatibilità nel low-code (o come far felice Dev-I)
La dura realtà delle imprese B2B è che, il più delle volte, si ha bisogno di riutilizzare dati e applicazioni create con una vecchia versione della piattaforma. La più vecchia applicazione Appian ancora funzionante è del 2008. Dev-I era ancora al liceo allora. Tuttavia, può capitare che riceva una richiesta per integrare quell'applicazione in una dell'ultima versione. Succede spesso con i nostri clienti.
Forse è per questo che Appian si impegna per garantire una retrocompatibilità semplice come quella di Xbox. “Spesso la retrocompatibilità mi rende felice e mi evita lavori più deprimenti”, dice Dev-I.
Facendo sì che le vecchie funzioni e applicazioni funzionino ancora meglio quando si passa a una nuova versione, eliminiamo il lavoro manuale più noioso e ripetitivo per gli sviluppatori di tutto il mondo.
L'ingegnere che è in me pensava che fosse troppo bello per essere vero. Ma quando ho sondato la Appian Community per vedere cosa dicono i nostri utenti sulla retrocompatibilità, ho notato questa risposta di Stefan Helzle, Manager di una multinazionale di servizi professionali.
Nessun problema dal 2010 grazie alla retrocompatibilità? Non male come risultato.
“Ci sacrifichiamo noi per non far soffrire voi” – Il punto di vista di un architetto del prodotto sulla retrocompatibilità
Ho parlato di retrocompatibilità anche con Matt Hilliard, Architetto del prodotto per la piattaforma Appian. Matt è uno sviluppatore OG che ha iniziato a codificare in Java nel 2003, prima di dedicarsi al low-code. Se c'è qualcuno che può illustrare nel dettaglio il nostro impegno nella retrocompatibilità, quello è Matt.
“Tutto il nostro processo interno è costruito sulla piattaforma Appian. Prima che un cliente riceva l'ultima versione, le nostre applicazioni critiche sono già in esecuzione sulla nuova versione. Se facciamo casino con la retrocompatibilità, ce ne rendiamo subito conto internamente”, dice Matt.
“Facciamo test di regressione approfonditi per garantire che le app esistenti continuino a funzionare. In un certo senso, ci sacrifichiamo per evitare ai clienti di soffrire”.
Abbiamo centinaia di applicazioni interne per gestire la nostra attività, tutte costruite su Appian. Se qualcosa non funziona in una nuova versione, si può stare sicuri che il team di sviluppatori di Matt ne sentirà parlare senza sosta prima che venga rilasciata al pubblico.
Nelle parole di Matt, possiamo individuare alcuni principi chiave per offrire una retrocompatibilità senza precedenti:
- Qualsiasi funzionalità - per quanto piccola - va tenuta e migliorata, in tutti i casi d'uso
- Bisogna programmare test di regressione automatizzati approfonditi e usare la piattaforma anche internamente
- Meglio presentare solo le funzionalità/impostazioni di cui i clienti hanno assolutamente bisogno, dato che andranno mantenute per anni
- Meglio affrettarsi a correggere i rari bug di retrocompatibilità che sfuggono ai controlli qualità
“I bug capitano. Gli errori capitano. I comportamenti possono variare. È così che va con le nuove versioni”, dice Matt. Non c'è dubbio, gli sviluppatori sono tipi pragmatici.
“Pertanto, ci impegniamo a risolvere sempre tempestivamente i problemi di retrocompatibilità, per quanto rari o poco usati dai clienti”.
Soluzioni pensate per gli sviluppatori
Se costruisci applicazioni per dispositivi mobili pubbliche - quelle che si comprano negli store - gli aggiornamenti saranno alla mercé delle aziende tecnologiche, che li effettuano quando e come vogliono loro.
I clienti di Appian, tuttavia, sono sviluppatori di applicazioni come Dev-I. Per cui dobbiamo trattarli bene.
Se costruisci un'app su Appian Cloud, l'aggiornamento alle nuove versioni è automatico e trasparente. Altrimenti, ci siamo impegnati per rendere la procedura più semplice possibile per gli sviluppatori.
Con quattro uscite all'anno, l'unico modo per riuscirci è offrire una retrocompatibilità completa.
All'ultimo controllo, ci sono oltre 2000 ruoli da sviluppatore Appian ancora disponibili su LinkedIn in tutto il mondo.
Oltre 2000 nuovi sviluppatori che entrano in azienda avendo a che fare con dati e applicazioni nati prima di loro. Senza contare le migliaia di sviluppatori Appian che già si trovano in questa situazione (Sì, Dev-I, sto parlando di te).
Con la retrocompatibilità, vogliamo concedere agli sviluppatori come Dev-I più tempo da dedicare ad attività intellettuali più elevate, da costruire nuovi codici interessanti a giocare a Nintendo Switch.
Per gli sviluppatori più curiosi
La filosofia seguita da Appian nel costruire app retrocompatibili è disponibile qui.
Tuttavia, so che gli sviluppatori in genere sono piuttosto curiosi. Chi volesse fare una prova gratuita di Appian può provare Appian Community Edition, un ambiente gratuito dove esplorare le nostre funzionalità.
Scegli uno dei corsi da "Builder" e fai una prova. Già che ci sei, puoi anche aspettare tre mesi per l'uscita della prossima versione e controllare la retrocompatibilità.
