Home | Blog | Data study

Costo del cambio di contesto: cosa rivelano 5 M di PR GitHub

Abbiamo sintetizzato dati da oltre 5 M di PR per misurare il vero costo del cambio di contesto per i developer – e non è dove pensi.

By Ellis Keane · 2026-03-29

Il costo del cambio di contesto citato dalla maggior parte degli articoli – 23 minuti per rifocalizzarsi dopo un'interruzione, dalla ricerca di Gloria Mark alla UC Irvine – è un risultato reale di uno studio reale. Ma misurava lavoratori della conoscenza in generale nel 2008, non ingegneri del software. E l'industria artigianale di post del blog che moltiplica 23 minuti per un numero stimato di interruzioni per produrre allarmanti cifre annuali in dollari (sempre accompagnate da una foto stock di qualcuno che si tiene la testa) sta facendo qualcosa che la ricerca originale non ha mai inteso.

Ho un interesse personale in questa domanda. In una società precedente, ho trascorso – e questo non è iperbole – tra l'80 e il 100 per cento di alcune giornate semplicemente come router umano. Non a scrivere codice, non a rivederlo. A instradare informazioni tra persone e strumenti, perché nessun sistema unico li connetteva. Quell'esperienza è in parte il motivo per cui abbiamo costruito Sugarbug, ma è anche il motivo per cui sono scettico riguardo ai calcolatori standard di costo del cambio di contesto. Misurano l'interruzione. Non misurano i giorni che trascorri senza mai arrivare alla cosa su cui avresti dovuto lavorare.

Volevamo quindi sapere cosa costa veramente il cambio di contesto nel lavoro di ingegneria – non in termini astratti di produttività del developer, ma misurato nell'artefatto che i team producono quotidianamente: le pull request. Abbiamo sintetizzato i risultati di tre studi su larga scala che coprono oltre 5 milioni di PR in migliaia di progetti open source, e abbiamo osservato cosa guida davvero il tempo di revisione delle pull request.

Il risultato principale: il cambio di contesto più costoso non è la notifica di Slack che spezza il tuo flusso. È la pull request che rimane in una coda di revisione per un giorno, costringendo l'autore a ricostruire un intero modello mentale quando le domande arrivano finalmente.

I Dataset da cui Abbiamo Attinto

Non abbiamo costruito uno scraper personalizzato e analizzato 10.000 PR in isolamento. Abbiamo sintetizzato i risultati di due studi peer-reviewed e un grande dataset industriale, poi abbiamo messo alla prova le loro conclusioni l'una contro l'altra.

stat: "3,35 Mio." headline: "Pull request analizzati da Zhang et al." source: "Pull Request Latency Explained: An Empirical Overview (Empirical Software Engineering, 2022)"

I tre dataset principali:

Zhang et al. (2022), peer-reviewed: 3.347.937 PR chiusi in 11.230 progetti. Ha utilizzato la regressione lineare a effetti misti per identificare cosa provoca ritardi nelle revisioni dei PR. Pubblicato in Empirical Software Engineering.
Adadot (2023), dataset industriale: Oltre 300.000 PR uniti da ~30.000 developer. Non peer-reviewed, ma il campione è ampio e la metodologia (correlazione tau di Kendall) è trasparente. Focalizzato sulle dimensioni dei PR rispetto al tempo di consegna.
Studio di revisione multipla (2019), peer-reviewed: 1.836.280 PR in 760 progetti GitHub. Pubblicato in Information and Software Technology. Esamina il comportamento di revisione concorrente – un proxy diretto del cambio di contesto nella revisione del codice.

Li abbiamo incrociati con il 2024 DORA State of DevOps Report e l'Atlassian Developer Experience Report 2024 (sondaggio su oltre 2.100 developer su cambio di contesto, produttività dei developer e il lato umano dell'equazione).

La Coda È il Vero Problema

Zhang et al. hanno rilevato che il tempo impiegato da un PR per ricevere la sua prima risposta – primo commento, prima revisione, qualsiasi cosa per prima – spiega il 58,7% della varianza nella durata totale del PR. È il predittore osservato più forte nel dataset – davanti alla dimensione del PR, alla complessità del codice o al numero di file modificati! Non è nemmeno vicino.

Il costo maggiore del cambio di contesto nella revisione del codice non è il cambio in sé – è la coda che si forma mentre tutti sono occupati a cambiare tra altre cose.

Pensa a cosa significa nella pratica. Un ingegnere apre un PR alle 10:00. Il revisore designato è immerso nel proprio ramo di funzionalità, o in riunione, o a smistare messaggi Slack (e onestamente, probabilmente tutte e tre in sequenza). Il PR aspetta. Quando qualcuno lo prende in carico alle 15:00, l'autore è già passato ad altro. Ora il revisore ha domande, il che significa che l'autore deve fare un cambio di contesto verso il codice che ha scritto cinque ore fa, ricostruire il modello mentale e rispondere. Quella risposta arriva alle 16:30, ma il revisore è andato a casa.

Il PR invecchia di un altro giorno.

I dati suggeriscono che questo è più un problema di code che un problema di disciplina – e il costo del cambio di contesto di quella coda si moltiplica in modi che i calcolatori di interruzioni mancano completamente.

I PR Piccoli Non Ti Salveranno

Hai già sentito questa: i PR più piccoli vengono revisionati più velocemente, quindi tieni i tuoi PR piccoli. Non è esattamente sbagliato, ma la dimensione dell'effetto è (genuinamente) più piccola di quanto ti aspetteresti.

L'analisi di Adadot su 300.000+ PR ha trovato una correlazione tau di Kendall di soli 0,06 tra la dimensione del PR e il tempo di consegna – un'associazione debole, sebbene lo studio non abbia riportato intervalli di confidenza per la cifra aggregata. I PR sotto le 100 righe hanno circa l'80% di probabilità di essere completati entro una settimana, il che suona bene finché non ti rendi conto che è lo stesso tasso di completamento di un PR che è rimasto sei giorni nella coda di revisione di qualcuno!

stat: "0,06" headline: "Correlazione tra dimensione del PR e tempo di consegna" source: "Analisi Adadot di 300.000+ PR da ~30.000 developer (2023)"

Il risultato più interessante: questa correlazione variava enormemente tra le organizzazioni, da 0,1 a quasi 0,7 a seconda dell'azienda. Il che suggerisce che la dimensione del PR non è intrinsecamente il collo di bottiglia – lo è la cultura di revisione e il processo attorno al PR. Un team con una cadenza di revisione solida può gestire PR più grandi in modo efficiente. Un team dove le revisioni sono un ripensamento faticherà con PR di qualsiasi dimensione.

La soglia delle 400 righe dello studio di revisione del codice SmartBear/Cisco regge come euristica utile – i dati di Adadot hanno anche trovato che il coinvolgimento nelle revisioni cala oltre quell'intervallo. Ma ottimizzare la dimensione dei PR senza correggere la cadenza di revisione sottostante è (e lo dico con genuina affetto per ogni engineering manager che ci ha provato) spostare i lettini sul Titanic.

Tutti Revisionano Tutto Contemporaneamente

Lo studio di revisione multipla ha rilevato che il 62% delle pull request coinvolge developer che stanno simultaneamente revisionando più PR. Più importante ancora, hanno trovato una correlazione statisticamente significativa: più revisioni concorrenti per revisore era associato a una latenza di risoluzione dei PR più lunga.

Il 62% delle pull request coinvolge developer che revisionano contemporaneamente più PR – e la revisione multipla correla direttamente con tempi di risoluzione più lunghi. attribution: Studio di revisione multipla di pull request, 1,8 Mio. di PR in 760 progetti

Il meccanismo è intuitivo (anche se lo studio, essendo osservazionale, non prova la direzione della causalità). Un revisore prende il PR n. 1, legge il diff, inizia a formarsi un modello mentale di cosa sta cercando di fare il codice. Poi arriva una notifica – il PR n. 2 ha bisogno di revisione perché sta bloccando un deployment. Il revisore cambia. Quando torna al PR n. 1, deve rileggere metà del diff perché il modello mentale è decaduto.

Scala questo a un team di otto ingegneri, ognuno con due o tre PR aperti, ognuno che revisiona per due o tre colleghi, e il costo di coordinamento inizia a spiegarsi da solo. Separatamente, il 2024 DORA Report ha rilevato che il cluster degli "high performer" si è ridotto dal 31% al 22% mentre il cluster dei low-performer è cresciuto dal 17% al 25%. DORA non isola la concorrenza delle revisioni dei PR come fattore, ma il crescente costo di coordinamento è un plausibile contribuente a quel cambiamento.

Cosa Sbagliano le Stime del Costo del Cambio di Contesto

Permettimi di essere diretto sulla cifra "$50.000 per developer all'anno" che circola ampiamente negli articoli sul costo del cambio di contesto. La metodologia alla base della maggior parte di queste stime è: prendi i 23 minuti di tempo di rifocalizzazione, moltiplica per il numero stimato di interruzioni giornaliere (di solito tra 6 e 15, a seconda di quanto si sente drammatico l'autore), moltiplica per una tariffa oraria del developer e annualizza.

Il problema non è che la matematica sia sbagliata. Il problema è che tratta tutti i cambi di contesto come equivalenti. Passare da una programmazione profonda a un messaggio Slack che chiede dove si pranza in team – quello è un cambio di contesto. Passare dalla revisione di un PR alla revisione di un PR diverso in una base di codice completamente diversa – anche quello è un cambio di contesto. Ma il costo cognitivo non è lontanamente paragonabile, e appiattirli tutti in un'unica tariffa oraria oscura dove avviene il vero danno.

Per dirlo in modo concreto: nell'ultimo lavoro, un giorno tipico significava spostarsi tra Notion, Linear, Mattermost, Proton Mail, Proton Calendar, Discord, Twitter, Farcaster e innumerevoli canali Telegram e Signal – e sono sicuro di dimenticarne almeno una mezza dozzina. Ora ne uso un manciata (Signal, Obsidian, Figma, GitHub, email, calendari). Il costo per cambio non è cambiato. Quello che è cambiato è quanti contesti erano in attesa di attenzione – e quali di essi contassero davvero.

I dati dei PR suggeriscono che i cambi costosi sono quelli che creano code, non quelli che interrompono il flusso. Un developer che viene pingato immediatamente (in minuti) per revisionare un PR e fa una veloce revisione di 50 righe – questa è una breve interruzione con un alto rendimento. Un developer che mette quella richiesta di revisione in coda insieme ad altre quattro e se ne occupa domani – questa è un'interruzione più lunga per il revisore ma crea un costo molto maggiore per l'autore e il team.

Cosa misurano i calcolatori di costo

Interruzioni individuali – quanto spesso il flusso di qualcuno si interrompe
Tempo di rifocalizzazione – quanto tempo per tornare al compito precedente
Moltiplicazione per la tariffa oraria – grandi numeri annuali spaventosi

Cosa mostrano davvero i dati dei PR

Formazione di code – PR in attesa della prima risposta
Concorrenza delle revisioni – revisori che gestiscono più PR contemporaneamente
Ritardi a cascata – i cambi di contesto dell'autore che amplificano i ritardi del revisore

Cosa Significa per il Tuo Team

Se stai cercando di ridurre il costo del cambio di contesto per i developer del tuo team, la risposta pratica è noiosa – il che è probabilmente il motivo per cui non se ne scrive molto. Non è uno strumento. Non è un framework di processo con un programma di certificazione. È la cadenza di revisione. (Lo so, lo so. Nessuno è mai stato promosso per aver migliorato la cadenza di revisione.)

I benchmark di ingegneria 2025 di LinearB, tratti da 6,1 milioni di PR in 3.000 organizzazioni, hanno rilevato che i team che raggiungevano tempi di ciclo élite (meno di 2,5 giorni) condividevano un tratto: revisionavano i PR rapidamente. Non perché avessero meno PR, o perché i loro PR fossero più piccoli (anche se spesso lo erano), ma perché rispondere alle richieste di revisione entro poche ore era una norma del team, non un ripensamento.

Per quel che vale, Ben e io – un team di due persone – mediamo minuti per la prima risposta ai PR, non ore. Non è un vanto di disciplina (non ce l'abbiamo). È un accordo di team: le richieste di revisione sono l'unica notifica che non si mette in coda. Le azioni CI e i test automatizzati gestiscono i controlli meccanici, il che significa che la revisione umana – la parte che richiede contesto reale – è più breve e avviene immediatamente. L'accordo è venuto prima. Gli strumenti l'hanno solo reso sostenibile.

In pratica, ciò significa:

Misura il tempo fino alla prima risposta, non solo il tempo di ciclo. Se stai monitorando le metriche DORA, aggiungi questa. È il predittore singolo più forte del throughput dei PR (spiega il 58,7% della varianza della durata di vita, secondo Zhang et al.).

Limita la concorrenza delle revisioni. Se un revisore ha tre richieste di revisione in sospeso, una quarta non riceverà comunque una buona revisione. I dati di revisione multipla hanno mostrato una chiara associazione tra concorrenza e latenza. Inizia con un limite WIP di due revisioni concorrenti e monitora l'impatto.

Smetti di ottimizzare le dimensioni dei PR in modo isolato. I PR piccoli sono utili, ma non sono un sostituto per un team che rivede davvero le cose. Un team che produce venti PR da 50 righe al giorno con un backlog di revisione di 48 ore sta peggio di un team che produce cinque PR da 200 righe con revisioni in giornata.

Riconosci che la revisione è lavoro vero. Il sondaggio Atlassian 2024 ha rilevato che il 69% dei developer perde 8+ ore settimanali a causa di inefficienze. La revisione non deve essere una di quelle inefficienze – ma solo se viene trattata come un'attività di ingegneria di prim'ordine, non come un'interruzione del lavoro "vero".

E qui c'è la parte che nessuno nello spazio degli strumenti di produttività (noi stessi inclusi, per essere onesti) vuole dire ad alta voce: l'intervento più impattante per il costo del cambio di contesto nei team di ingegneria non è uno strumento. È un accordo di team su quando vengono revisionati i PR. Se la norma implicita del tuo team è "mi occuperò delle revisioni quando ho un momento libero", nessuna quantità di strumenti impedirà la cascata di code che i dati dei PR rivelano.

Gli strumenti aiutano – essere in grado di vedere il contesto completo di un PR senza aprire quattro schede del browser riduce il carico cognitivo per cambio, e mettere in evidenza quali revisioni stanno bloccando il lavoro degli altri aiuta a stabilire le priorità. Ma la leva centrale è l'accordo, e gli accordi sono gratuiti. Nessun calcolatore da 23 minuti richiesto.

Il cambio di contesto più costoso non è la notifica che spezza il tuo flusso. È la richiesta di revisione che rimane in una coda per un giorno, costringendo l'autore a ricostruire il contesto mentale quando le domande arrivano finalmente.

Ricevi l'intelligence dei segnali direttamente nella tua casella di posta.

Domande Frequenti

Q: Quanto costa il cambio di contesto per developer all'anno? A: Le stime variano, ma la ricerca sottostante è più esile di quanto suggeriscano la maggior parte degli articoli. Lo studio di Gloria Mark alla UC Irvine ha rilevato 23 minuti di tempo di rifocalizzazione per interruzione, e il sondaggio Atlassian 2024 su oltre 2.100 developer ha riscontrato che il 69% perde 8+ ore settimanali a causa di inefficienze. La cifra in dollari dipende fortemente dalle ipotesi salariali, dalla frequenza delle interruzioni e da come si definisce "cambio" – per questo ci siamo concentrati sui dati dei PR.

Q: Sugarbug aiuta a ridurre il cambio di contesto per i team di ingegneria? A: Sì. Sugarbug connette strumenti come Linear, GitHub, Slack e Figma in un unico grafo della conoscenza, in modo che gli ingegneri possano vedere il contesto completo di un'attività – il PR pertinente, la discussione su Slack, il commento su Figma – senza aprire quattro schede. L'obiettivo è meno cambi, non meno strumenti.

Q: Qual è la dimensione ideale di una pull request per minimizzare i ritardi di revisione? A: La ricerca dell'analisi di Adadot su 300.000+ PR ha rilevato che i PR con meno di 100 righe di codice hanno circa l'80% di probabilità di essere completati entro una settimana. Oltre le 400 righe, sia la qualità della revisione sia la velocità di completamento calano. I PR più piccoli riducono anche il carico di cambio di contesto del revisore.

Q: Sugarbug si integra con le pull request di GitHub? A: Sì. Sugarbug raccoglie l'attività di GitHub – PR, commenti, revisioni e cambiamenti di stato – e le collega ai segnali correlati negli altri tuoi strumenti. Se un issue di Linear ha generato il PR e un thread di Slack ha discusso l'approccio, Sugarbug li collega tutti e tre automaticamente.

Q: Da dove viene la statistica dei "23 minuti per rifocalizzarsi"? A: Proviene dalla ricerca di Gloria Mark alla UC Irvine, pubblicata in "The Cost of Interrupted Work: More Speed and Stress" (CHI 2008). Lo studio ha rilevato che i lavoratori impiegavano in media 23 minuti e 15 secondi per tornare al proprio compito originale dopo un'interruzione. Vale la pena notare che lo studio ha osservato lavoratori della conoscenza in generale, non ingegneri del software in modo specifico.