Removing Noise or Introducing Bias? The Hidden Cost of MSR Filtering

Immaginate Internet come una gigantesca e caotica biblioteca dove chiunque può costruire uno scaffale e chiamarlo biblioteca. Questo è il mondo del Software Open Source (OSS), un enorme parco giochi digitale dove milioni di persone — dagli studenti che testano nuove idee di programmazione agli sviluppatori professionisti che costruiscono la prossima grande app — conservano i propri progetti. I ricercatori, che sono come detective che cercano di risolvere misteri su come funziona il software, amano visitare questa biblioteca. Esaminano gli scaffali, guardando quante persone hanno "messo mi piace" a un progetto (le stelle), quante volte le persone hanno cambiato i libri (i commit) e quante persone hanno aiutato a scriverli. Questi indizi li aiutano a comprendere i segreti dell'ingegneria del software. Ma ecco l'inghippo: la biblioteca è così vasta che è piena di scatole vuote, manichini da prova e scarabocchi incompiuti. Per trovare i libri "veri", i ricercatori di solito scartano tutto ciò che non sembra abbastanza popolare o impegnato. Usano regole come: "Se un progetto non ha almeno 10 stelle, è solo rumore, quindi buttiamolo via".

Ma cosa succederebbe se quelle regole stessero scartando le storie più interessanti? E se, nel nostro tentativo disperato di pulire la biblioteca, finissimo accidentalmente per nascondere il fatto che la maggior parte dei libri è in realtà abbandonata, o che finiamo solo per leggere quelli scritti dagli stessi pochi autori famosi? Questa è la grande domanda che i ricercatori Mohit Kaushik e Jyoti Bawa si stanno ponendo. Sono preoccupati che i filtri stessi che gli scienziati usano per rendere i loro dati "puliti" possano rendere i loro risultati "sporchi", nascondendo la vera, disordinata realtà di come i progetti software vivano e muoiano.

Il Grande Filtro: Pulire i Dati o Nascondere la Verità?

In questo studio, gli autori hanno deciso di giocare a un gioco di "E se...?" con una massa enorme di dati. Hanno esaminato 1,57 milioni di repository di software da una piattaforma chiamata SEART. Pensate a questo dataset come a un enorme secchio di mattoncini LEGO mescolati. Alcuni sono grandi castelli colorati; altri sono minuscoli mattoncini rossi singoli; e molti sono solo pezzi rotti che nessuno ha mai finito.

Di solito, i ricercatori guardano questo secchio e dicono: "Ok, vogliamo solo i grandi castelli finiti. Buttiamo via tutto ciò che ha meno di 10 stelle (mi piace) o meno di 10 commit (cambiamenti)". Gli autori hanno testato cosa succede quando applicano queste regole rigide, come alzare il volume di un filtro finché non diventa davvero forte.

Il costo nascosto della "Popolarità"
Quando i ricercatori hanno applicato un "filtro di popolarità" (guardando solo ai progetti con più stelle), hanno scoperto qualcosa di sorprendente. Mentre alzavano la soglia delle stelle da 10 a 1.000, il progetto "medio" nel loro campione non diventava solo leggermente migliore; diventava 7 volte più grande. I progetti diventavano più vecchi, avevano più persone che ci lavoravano e avevano molta più probabilità di avere una licenza formale (come un libro di regole).

Ma ecco il colpo di scena: inseguendo i progetti popolari, hanno completamente perso di vista la realtà. Nel loro secchio originale, non filtrato, il 73,42% dei progetti era in realtà inattivo o "abbandonato". Tuttavia, man mano che filtravano per popolarità, questo numero diminuiva. Quando guardavano solo i progetti super popolari (1.000+ stelle), i dati facevano sembrare che solo il 50,65% fosse abbandonato. Il filtro non ha solo rimosso il rumore; ha nascosto il fatto che la maggior parte dei progetti fallisce o viene lasciata indietro. È come se chiedeste solo alle persone di successo in una città riguardo al loro lavoro, e poi concludeste che "la disoccupazione è bassa" perché non avete mai parlato con le persone che hanno perso il lavoro.

La trappola dell' "Attività"
Gli autori hanno anche testato i "filtri di attività", che mantengono solo i progetti con un alto numero di commit (cambiamenti). Questo era ancora più estremo. Quando hanno filtrato per alta attività, la dimensione media del progetto è cresciuta di 18 volte! Questi filtri hanno anche cambiato la "personalità" del software. Ad esempio, i progetti che utilizzano il linguaggio C++ erano comuni nei gruppi con soglie inferiori, ma scomparivano dai primi 5 quando il filtro diventava rigido. Nel frattempo, TypeScript e Go sono diventati molto più comuni nelle liste filtrate.

Lo studio suggerisce che questi filtri non sono neutrali. Agiscono come un setaccio che lascia passare solo tipi specifici di progetti: progetti infrastrutturali più vecchi, enormi e ben finanziati. Spingono fuori i progetti più piccoli, nuovi o sperimentali, anche se quei progetti più piccoli sono reali e attivi.

Il traffico delle relazioni
Forse la scoperta più giocosa (e pericolosa) riguarda come questi filtri stravolgono le relazioni tra diverse cose. Immaginate di cercare di capire se "lavorare sodo" (commit) porti a "essere popolari" (stelle). Nel mondo reale, disordinato (il dato di base), queste due cose sono solo debolmente connesse. Ma quando i ricercatori hanno applicato i loro filtri, la connessione è improvvisamente sembrata fortissima.

Per esempio, il legame tra "commit" e "dimensione del progetto" è passato da un moderato 0,466 a un fortissimo 0,808 nel gruppo filtrato per attività. Gli autori spiegano che questo non accade perché i progetti siano cambiati; è perché il filtro ha costretto le cose ad apparire tali. Solo mantenendo i progetti grandi e frenetici, il filtro ha fatto sembrare che "i grandi progetti abbiano sempre molti commit", quando in realtà la relazione è molto più complicata. È come se studiaste solo i giocatori di basket più alti e concludeste che "l'altezza è l'unica cosa che conta nello sport", ignorando tutti gli altri.

Il Verdetto: Non buttate via il rumore

Gli autori concludono che, sebbene abbiamo bisogno di pulire i nostri dati, non possiamo usare regole arbitrarie come "10 stelle" o "500 commit" senza riflettere. Queste regole sono come un martello cieco: spazzano via il "rumore", ma spazzano via anche la verità. Creano un'immagine distorta in cui i progetti software sembrano più di successo, più vecchi e più uniformi di quanto non siano in realtà.

Inveve di filtrare ciecamente, gli autori suggeriscono ai ricercatori di utilizzare il campionamento stratificato. Immaginate di prendere una cucchiaiata dal secchio dei LEGO che contenga un mix equo di grandi castelli, piccole case e pezzi rotti, piuttosto che scegliere solo i castelli più grandi. Suggeriscono anche agli scienziati di ripensare a cosa conti come "rumore". Forse un progetto con zero stelle non è solo un esperimento fallito; forse è un gioiello nascosto che non è ancora stato scoperto.

In breve, questo articolo ci avverte che, nella nostra fretta di trovare i dati "perfetti", potremmo costruire un castello di carte che sembra perfetto all'esterno ma che crolla non appena proviamo a comprendere il mondo reale e disordinato del software. Gli autori non dicono di smettere di filtrare del tutto, ma suggeriscono fortemente di smettere di usare queste regole "taglia unica" e di iniziare a essere più attenti a ciò che stiamo buttando via.