Il caso di "rutto.mp3": il piccolo suono e il vero problema dello sviluppo

Qualche settimana fa, una notizia curiosa ha conquistato le homepage di numerose testate, non solo informatiche: all’interno dell’app iOS di un rinomato istituto bancario italiano è stato individuato un file audio. Nulla di straordinario, si potrebbe pensare, considerando che molte app, come quelle di social network famosi, utilizzano file audio per notifiche o effetti sonori. Basti pensare, ad esempio, ai suoni distintivi riprodotti quando riceviamo messaggi o interagiamo con determinate funzionalità di app come Facebook, WhatsApp o Messenger.

La particolarità, tuttavia, risiedeva nel nome di quel file: "rutto.mp3". Sì, un rutto. Da quel momento, l’attenzione si è riversata su una serie di aspetti critici: dalle dimensioni eccessive dell’app alla presenza di framework apparentemente superflui, passando per immagini codificate in Base64 che non avevano motivo di essere lì. Un insieme di elementi che stridevano con l’idea di affidare i propri risparmi a un'app che, sulla carta, dovrebbe incarnare serietà e sicurezza. Ma c’è un aspetto meno evidente – e a mio avviso troppo trascurato – che merita di essere portato alla luce: un tema che affonda le radici ben oltre il clamore mediatico, cioè il fattore umano, ovvero la reale situazione in cui spesso i team di sviluppo si trovano a lavorare.

Cosa è successo?

Prima di tutto, vale la pena ricordare brevemente i fatti dietro il caso "rutto.mp3".

Le app moderne, inutile negarlo, tendono spesso ad avere dimensioni considerevoli, a volte esagerate. Certo, non siamo più nell’era degli 8 bit, quando ogni singolo byte sul Commodore 64 andava ottimizzato al millimetro. Tuttavia, lo spazio di archiviazione sui nostri dispositivi non è infinito – anzi, in molti casi ha un costo significativo – e gli utenti hanno iniziato a prestare maggiore attenzione a come viene utilizzato.

Il caso "rutto.mp3" è emerso proprio da qui: l’app bancaria in questione occupava ben 700 MB. Questo ha spinto alcuni utenti a esaminarne il bundle IPA utilizzando EmergeTools (i cui dettagli sono disponibili qui), portando alla luce scoperte tanto curiose quanto imbarazzanti.

• Un numero spropositato di framework dinamici, responsabili di circa il 60% del peso complessivo del bundle.
• La presenza del file audio "rutto.mp3".
• Un file di testo contenente l’immagine di una modella, codificata in Base64.

Ad oggi, le dimensioni dell’app sono rimaste pressoché invariate, ma i due file sopra citati sono stati rimossi.

Non sorprende, quindi, che questa app sia diventata bersaglio di critiche da parte sia degli utenti che della stampa. Critiche che si sono mosse su due binari: da un lato, l’aspetto tecnico; dall’altro, il prodotto finale. Ma andiamo con ordine.

Framework statici vs dinamici

Per cominciare, parliamo di alcune delle questioni di natura tecnica che sono emerse come conseguenza dell'analisi fatta su EmergeTools.

Una delle cose che mi ha colpito in particolare è l'eccessiva attenzione che le testate di settore, e non, hanno dato alla presenza dei "framework dinamici", additandoli come i principali colpevoli delle eccessive dimensioni dell'app. Ma sarà tutto vero?

• Effetti dei framework statici sulle dimensioni: impostare i framework come statici può aiutare a ridurre le dimensioni dell'app se si attiva il dead code stripping. Dato che i framework statici sono linkati a build-time, è possibile individuare tutti i simboli non utilizzati ed escluderli dall'eseguibile dell'app, riducendone le dimensioni.
• L'uso di framework statici riduce i tempi di caricamento: l'integrazione di framework statici riduce i tempi di caricamento dell'app, con il compromesso di avere tempi di build più lunghi, grazie alla strategia di caricamento in memoria dei simboli in essi contenuti. I framework dinamici vengono tutti caricati in memoria al lancio dell'app tramite dyld, di conseguenza maggiore è il numero di framework da caricare, maggiore sarà il tempo di caricamento
• Passare ai framework statici può ridurre le dimensioni dell'app del 50%: non è necessariamente vero, in quanto dipende dall'uso che gli sviluppatori fanno dei framework dinamici. Laddove non ci sia un'ottimizzazione significativa a valle del dead code stripping, le dimensioni del bundle finale potrebbero non ridursi significativamente

Una delle critiche più frequenti è rivolta al numero di framework usati nell'app è esagerato. Non è necessariamente un problema, o come piace dire a noi sviluppatori "dipende". In molti casi, è assolutamente legittimo integrare un gran numero di framework in un’app. Uno dei principi cardine dello sviluppo software è "non reinventare la ruota": se esiste una libreria che soddisfa le nostre esigenze, spesso è più sensato adottarla piuttosto che scrivere codice ex novo.

Optare per una soluzione personalizzata, infatti, può aumentare i tempi e i costi di sviluppo, senza dimenticare che anche quel codice finirebbe comunque per occupare spazio nel bundle. Un altro aspetto da considerare è che il numero di framework spesso non dipende direttamente dagli sviluppatori, ma dalle cosiddette "dipendenze delle dipendenze": non è raro avere un Podfile con una decina di pod e ritrovarsi un workspace che include decine di librerie secondarie, tutte necessarie al funzionamento delle principali.

Certo, è importante non cadere nella trappola di utilizzare librerie sovradimensionate – quelle che offrono 100 funzionalità, quando a noi ne serve solo una manciata – ma l’adozione di framework rimane una pratica standard e, se gestita correttamente, non dovrebbe essere vista come un problema in sé.

È comunque oggettivo che questa app abbia un numero di dipendenze troppo alto e che rimuoverle potrebbe essere molto oneroso. Il framework bloat in progetti lunghi e complessi è un fenomeno tutt’altro che raro. Questo problema è spesso legato alla natura stessa dei progetti di lunga durata, dove il ricambio fisiologico degli sviluppatori e un KT carente, o del tutto assente, gioca un ruolo determinante.

Rumori molesti e modelle: e il controllo qualità?

Certo, a primo impatto può far sorridere sapere che in una delle app installate sul nostro iPhone sono presenti file audio che riproducono rumori molesti, oppure volti di modelle codificati in Base64. In questi casi è importante non cadere nella facile trappola di generalizzare pensando che un suono o un'immagine siano uno spreco gravissimo di spazio.

Obiezione! Vostro Onore, anche Facebook, Messenger e WhatsApp hanno suoni personalizzati al loro interno!

Anche app come Facebook, Messenger, WhatsApp o X presentano suoni personalizzati al loro interno. Basti pensare al suono riprodottto quando si riceve una notifica, oppure a quello riprodotto quando facciamo pull-to-refresh sul feed di Facebook. Lo stesso "rutto.mp3" occupava 5 KB, dimensioni infinitesimali rispetto ai 700 MB dell'app, quindi non ha molto senso inquadrare il problema nei termini dello spreco di spazio.

Il tema della presenza di contenuti sconvenienti all’interno di un’app mette in evidenza un problema con diverse sfaccettature. Le critiche, del tutto comprensibili, nascono dal fatto che questi contenuti si trovavano in un'app bancaria, un tipo di applicazione che, gestendo i risparmi degli utenti, è naturalmente soggetta ad aspettative di serietà e sicurezza superiori rispetto ad altre categorie di app.

Tra le possibili cause avanzate da più parti, c’è la mancanza di un processo di QA strutturato; alcune opinioni più dure arrivano persino a parlare di negligenza durante i controlli. Va detto, però, che solo il team di sviluppo può sapere cosa sia realmente accaduto, ed è impossibile per chi osserva dall’esterno determinare se queste affermazioni siano fondate o meno.

Inoltre, non è scontato che individuare un file come inutile o inopportuno rientri nel perimetro di un normale test di QA. È interessante notare, infatti, che l’identificazione dei due file controversi non è avvenuta durante il QA interno, ma grazie a una code review condotta da terzi con l'ausilio di uno strumento esterno.

Personalmente mi sento di escludere la pista dello scherzo: scherzi di questo tipo si pagano molto caro, sia in termini di credibilità che di conseguenze professionali. Con tutta probabilità, si tratta semplicemente di una svista: un file audio inserito durante lo sviluppo per testare una funzionalità in attesa del suono definitivo. Che poi questo file non sia stato rimosso per distrazione o per semplice sciatteria è qualcosa che probabilmente non sapremo mai.

Va anche detto che, per quanto utile e importante sia un processo di QA strutturato, non è una garanzia assoluta contro ogni tipo di errore o svista. Alcuni problemi possono sfuggire, soprattutto in progetti complessi o con tempistiche serrate. Un esempio emblematico è il recente caso CrowdStrike, che ha messo in ginocchio l’informatica globale: un episodio che dimostra come anche sistemi altamente sofisticati e processi consolidati possano fallire nel prevenire certi problemi. In definitiva, la perfezione nel software rimane un obiettivo ideale, ma estremamente difficile da raggiungere nella pratica.

Le condizioni di lavoro nello sviluppo: è se fosse questo il vero problema?

Non giriamoci intorno: le app bancarie, così come tutte le altre, sono progettate, sviluppate, controllate e mantenute da esseri umani. Tutti i sistemi di controllo, i flussi di lavoro e i test a cui vengono sottoposte le app sono strumenti utili, ma, come tali, sono creati dalla mente umana e quindi inevitabilmente soggetti a errori. Sta poi a noi utilizzarli nel miglior modo possibile.

1980: il primo easter egg nella storia dei videogiochi in Adventure per Atari 2600, nato dal malcontento di uno sviluppatore nei confronti del management di Atari

Personalmente credo che il vero problema, di cui si è parlato troppo poco, siano le condizioni di lavoro in cui molto spesso si trovano a lavorare gli sviluppatori del software. Casi come quello di "rutto.mp3" sono sempre successi nel mondo dell'informatica e possiamo stare certi che accadranno ancora. Ma perché questo avviene? Alcune possibili ragioni sono:

• Personale con competenza inadeguata al progetto: gli sviluppatori sono spesso buttati nella mischia, quasi come fossero carne da cannone. È un paragone brutale, ma secondo me assolutamente calzante. La formazione tecnica per affrontare il nuovo progetto e il tempo necessario per prendere confidenza con il codice sono spesso le prime cose che vengono tagliate per stare nei costi. C'è chi la chiama "formazione on the job", ma la realtà è che ci si ritrova con una squadra di sviluppatori junior che fanno già fatica a compilare il progetto, di conseguenza aggiungendo maggior carico di lavoro sulle risorse più anziane e sui loro supervisori.
• Ricambio di risorse e KT inadeguato: nei progetti di lunga durata, in particolare quelli molto grandi, il ricambio degli sviluppatori è fisiologico. Purtroppo, molte volte questo fenomeno non è fronteggiato con la predisposizione di knowledge transfer adeguato. In alcuni casi, si tratta di un problema di mentalità dell'azienda. In queste situazioni il KT è visto come uno spreco di tempo, in cui lo sviluppo continuo di funzionalità ha la massima priorità e l'essere abili a lavorare al progetto è semplicemente un problema di qualcun altro. Altre volte si pensa che lo sviluppatore sia un essere onnisciente, che ha bisogno di leggere velocemente il codice dell'app per essere in grado di lavorarci. In assenza di documentazione chiara o di una fase di onboarding strutturata, i nuovi sviluppatori tendono a introdurre non solo nuovi framework, ma anche nuove soluzioni per risolvere problemi specifici, senza avere piena consapevolezza delle librerie e degli algoritmi già in uso. Per non parlare degli asset grafici: vi è mai capitato di trovare più copie della stessa icona da mettere su quel bellissimo pulsante back? Questo porta, nel tempo, a una proliferazione incontrollata di dipendenze, codice e asset e, a lungo andare, ad un'app scarsamente manutenibile.
• Mancanza di una vera fase di manutenzione: partiamo col dire che la manutenzione di un'app non significa esclusivamente risoluzione dei suoi bug. La manutenzione dell'app è anche quell'attività in cui si aggiornano le sue librerie, si adegua il codice alla nuova versione di iOS in procinto di uscire, si fa un po' di pulizia dopo una lunga fase di sviluppo di nuove funzionalità. È ovvio che per fare questo sia necessaria la presenza di un vero e proprio team di application maintenance, a cui il team di progetto possa affidare il proprio prodotto una volta terminato lo sviluppo. Nei casi peggiori, questo team è del tutto assente e la manutenzione è di fatti completamente a carico del team di progetto che, il più delle volte, non riesce ad andare oltre il classico bug fixing. Tutte le altre operazioni di manutenzione vengono quindi fatte in best effort (cosa pericolosissima, dato che il best effort non è mai sufficiente per risolvere le problematiche più delicate), nei casi peggiori quando ormai si è talmente vicini al disastro che non si ha spazio per commettere nemmeno un errore. Consideriamo il caso del framework bloat descritto prima: pensate davvero che gli sviluppatori non sappiano che tutte quelle librerie rendono l'app scarsamente manutenibile? Basta solo pensare a quanto tempo gli costi buildare 700 MB di app, per immaginare che siano i primi a voler risolvere questo problema. Un problema come questo non può, però, essere affrontato semplicemente staccando una libreria e osservare le conseguenze. L'app potrebbe non compilare, oppure potrebbe compilare ma un eventuale bug potrebbe non essere così semplice da individuare. È quindi chiaro che una operazione del genere va considerata un progetto vero e proprio, ma finché vince la mentalità del "finché funziona, lasciamo tutto com'è", non si può far altro che continuare costruire su fondamenta molto molto instabili.
• Sovrasfruttamento delle risorse: non è inusuale sentire di sviluppatori che lavorano oltre orario per centrare scadenze sfidanti. E non è altrettanto inusuale che queste persone, soprattutto i profili più senior, si trovino a lavorare parallelamente su più progetti, trovandosi spesso impossibilitati a delegare parte delle attività ad altri. La quotidianità di uno sviluppatore, inoltre, non si ferma alla mera produzione del codice. Gli sviluppatori sono infatti coinvolti in riunioni, devono far fronte ad emergenze improvvise, devono dare supporto ad altri colleghi. In tutto questo è facile inserire un file sconveniente nel progetto, con il solo obiettivo di non restare bloccati nello sviluppo e farsi allo stesso tempo una bella risata. Non voglio difendere la categoria a tutti i costi, a volte gli sviluppatori sono semplicemente negligenti e quindi per sciatteria o menefreghismo non si curano di pulire la propria sporcizia. Tuttavia, in una giornata bella piena, con tutto lo stress accumulato, senza contare i problemi che la risorsa può avere nel contesto extra-lavorativo, non è del tutto campata in aria l'idea che le continue distrazioni siano alla base di fenomeni come quello di "rutto.mp3". Non mi stancherò mai di ricordare alle persone che lavorano con me di fare attenzione a non committare sui nostri repository contenuti sconvenienti, siano essi immagini improprie, siano esse semplici parolacce nei commenti del proprio codice.
• Scarso riconoscimento: In Italia, lo sviluppo software è spesso visto come la versione digitale del lavoro in fabbrica, dove lo sviluppatore viene considerato poco più che una parte della catena di montaggio. In molti casi, la figura dello sviluppatore è percepita esclusivamente come un costo da contenere, e come sappiamo, i costi tendono ad essere visti negativamente. Questo approccio porta a una grave sottovalutazione del valore umano e intellettuale che ogni sviluppatore apporta al progetto. La mancanza di opportunità di crescita professionale e di riconoscimento adeguato contribuisce a creare un ambiente di lavoro demotivante, con un impatto diretto sulla soddisfazione e sull’efficacia delle risorse di sviluppo. Questo è particolarmente evidente quando gli sviluppatori sentono di dover sacrificare parte della propria vita personale per un progetto, senza che il loro impegno venga adeguatamente apprezzato o ricompensato. Un team di sviluppo demotivato, purtroppo, espone un progetto a rischi considerevoli, che vanno da inefficienze operative a danni ben più gravi, come errori critici nel codice o, nel peggiore dei casi, il fallimento del progetto stesso. La scarsa motivazione può anche tradursi in un alto tasso di turnover, con il conseguente aumento dei costi e dei tempi di sviluppo.

In sintesi, il caso del "rutto.mp3" non è solo un episodio di cattivo gusto, ma un campanello d’allarme su come, nella frenesia dello sviluppo e nella mancanza di risorse adeguate, gli sviluppatori possano commettere errori che vanno ben oltre il codice. Lavorare sotto pressione, con scadenze strette e senza un adeguato supporto, può portare a situazioni in cui dettagli apparentemente insignificanti sfuggono alla supervisione. Tuttavia, non dobbiamo dimenticare che, sebbene sia sempre importante migliorare i processi e le pratiche di QA, la qualità del lavoro dipende anche da un ambiente di lavoro sano, che permetta agli sviluppatori di lavorare al meglio delle proprie capacità. È qui che si gioca la vera sfida: non solo nel monitorare il codice, ma anche nel migliorare le condizioni di lavoro e nel garantire che ogni membro del team abbia le risorse necessarie per svolgere il proprio ruolo al meglio.

La discussione che emerge da casi come questi dovrebbe portarci a riflettere su come possiamo migliorare i nostri processi di sviluppo, senza mai dimenticare che dietro a ogni bug o svista ci sono persone, con le proprie difficoltà e pressioni quotidiane. La qualità del software non dipende solo dalla perfezione del codice, ma anche dall’equilibrio tra competenze, tempo e benessere del team. In definitiva, "rutto.mp3" è solo un campione di un problema più grande, che riguarda l’intero settore dello sviluppo software, con il quale dobbiamo imparare a confrontarci e a migliorare costantemente.

Fonti

DDay.it - 2024 - "L’app per iPhone di Banca Intesa occupa quasi 700 MB. Ma c’è spazio per l’mp3 di un rutto" - https://www.dday.it/redazione/51463/lapp-per-iphone-di-banca-intesa-occupa-quasi-700-mb-ma-ce-spazio-per-lmp3-di-un-rutto

DDay.it - 2024 - "Intesa San Paolo ripulisce l’app e nel farlo mette in luce un problema più serio" - https://www.dday.it/redazione/51503/intesa-san-paolo-ripulisce-lapp-e-nel-farlo-mette-in-luce-un-problema-piu-serio

Trevor Elkins & Max Topolsky - 2022 - "Static vs Dynamic Frameworks on iOS — a discussion with ChatGPT" - https://www.emergetools.com/blog/posts/static-vs-dynamic-frameworks-ios-discussion-chat-gpt

Puoi trovare questo articolo anche su LinkedIn, sul mio profilo. Se il mio articolo ti piace, lascia un commento e metti un like sul mio post qui: https://www.linkedin.com/posts/luca-cappellaro_iosdevelopment-iosdev-projectmanagement-activity-7282674914329808897-ylkA