Migliorare continuamente la produttività degli sviluppatori in Snowflake

Spesso mi chiedono: “Perché sei entrata in Snowflake e perché hai scelto di lavorare sulla produttività degli sviluppatori?” Sono entrata in Snowflake per imparare da ingegneri di altissimo livello e essere parte di una cultura altamente collaborativa. Queste sono state la ricetta segreta per la crescita spaziale di Snowflake. Snowflake stava iniziando una trasformazione straordinaria della produttività degli sviluppatori e dovevo saltare sulla nave spaziale mentre decollava!

Partiamo dall’inizio. Nel 2012, Benoit Dageville e Thierry Cruanes hanno fondato Snowflake. Ingegneri con esperienza nel campo dei database, hanno scritto gran parte del codice che ancora oggi utilizza Snowflake. I nostri fondatori credono che ogni ingegnere debba scrivere il codice, indipendentemente dall’anzianità. Il lavoro pratico consente ai nostri architetti senior e CTO di vedere la realtà sul campo della produttività degli sviluppatori e comprendere più accuratamente le difficoltà quotidiane, la fattibilità delle tempistiche e i compromessi sulle soluzioni.

Snowflake ha conosciuto una rapida crescita e ha assunto i migliori talenti, producendo una base di codice in rapida espansione. Essendo un’azienda monoprodotto, il prodotto Snowflake è diventato inevitabilmente più complesso e ricco di funzionalità nel tempo. Di conseguenza, nel corso degli anni, le nostre risorse collaterali di test sono cresciute in modo incontrollato, l’ambiente di sviluppo è diventato sempre più complesso e i tempi di creazione e test si sono notevolmente allungati, con effetti negativi sulla produttività degli sviluppatori. Inoltre, l’infrastruttura che supportava i nostri sistemi era inaffidabile sotto carichi pesanti, costringeva a tentativi manuali e frustrava gli sviluppatori con perdite di produttività. Nonostante i primi sforzi, centralizzare e scalare i nostri strumenti non ha avuto successo.

All’inizio del 2023 abbiamo avviato iniziative per migliorare l’integrazione continua (CI) e gli ambienti di sviluppo, ma i progressi sono stati lenti. Entro la fine del 2023, la strategia ha richiesto un ripensamento per metterla in moto.

Abbiamo identificato quattro ingredienti chiave per la ripartenza: priorità alla leadership, misurazione, connessione con il cliente e responsabilità.

Priorità alla leadership

La nostra leadership definisce la produttività degli sviluppatori una priorità assoluta per l’intera azienda, con revisioni mensili del CEO e dei dirigenti. S Muralidhar, CTO di Snowflake, è profondamente coinvolto nella definizione degli obiettivi in tutta l’azienda e guida i team cross-company che svolgono il lavoro vero e proprio. La produttività degli sviluppatori ha avuto un aumento del numero di dipendenti. Nel frattempo, i volontari di tutta l’azienda si sono attivati per eseguire il refactoring del codice e migliorare la configurazione dei test e i tempi di esecuzione per accelerare la riconversione del nostro sistema di build e degli ambienti di sviluppo. 

Misurazione

La misurazione è la chiave per capire se stiamo facendo progressi. È fondamentale misurare il successo percepito dal punto di vista del cliente, e non la nostra capacità di centrare obiettivi interni. A tale scopo, raccogliamo una combinazione di metriche qualitative e quantitative:

• Metriche operative del prodotto: uptime del sistema di build; numero totale di comandi del sistema di build al giorno

• Metriche del prodotto percepite dall’utente: build e test di latenza; percentuale di spazi di lavoro sani; adozione di nuovi sistemi 

• Metriche di output del percorso utente: numero medio di PR per sviluppatore a settimana; latenza del ciclo di vita delle PR in ogni fase, dalla presentazione delle PR, prima revisione e ultima revisione all’unione

• Sentiment complessivo degli sviluppatori: CSAT trimestrale (basato su sondaggi); principali aree di difficoltà

Abbiamo fissato ambiziosi obiettivi trimestrali basati su metriche e li monitoriamo attentamente. Nella nostra revisione settimanale delle operazioni, esaminiamo in profondità le anomalie nelle metriche e guidiamo alla risoluzione. Quando le metriche non sono sufficientemente connesse all’esperienza di sviluppo, le rivediamo e raccogliamo i feedback degli utenti aggiornati per garantire la coerenza con l’esperienza di vita degli utenti.

Connessione con il cliente

I nostri clienti sono ingegneri Snowflake esigenti. Per meritare la loro fiducia e creare il circolo virtuoso del feedback e dell’iterazione, dobbiamo dimostrare di 1) comprendere le loro esperienze, 2) progredire costantemente e 3) ridefinire le priorità e iterare in base al loro feedback.

Quando spingono per il cambiamento, i nostri clienti si dividono in tre categorie: early adopter, follower e ritardatari. Gli early adopter sono fondamentali per fornire feedback critici che ci aiutino a iterare e promuovono l’innovazione presso i loro team come addetti ai lavori di fiducia per promuovere l’adozione. Abbiamo identificato gli early adopter come campioni in ogni team e condotto colloqui regolari per tenere d’occhio i progressi e il sentiment. 

Abbiamo analizzato il feedback degli utenti nei sondaggi trimestrali come strumento chiave per dare priorità alla pianificazione trimestrale. Abbiamo condotto frequenti interviste con utenti di diversi gruppi di prodotti, analizzando per anzianità, principali linguaggi di programmazione e posizioni geografiche. Abbiamo utilizzato questo feedback per ottimizzare le priorità negli sprint mensili. Poiché ogni località geografica differisce per il ritmo del team e la modalità di comunicazione preferita, ci siamo recati da ogni team di area funzionale per capire quale fosse il forum migliore in cui interagire con gli sviluppatori locali. Inoltre, chiudiamo sempre il loop con i clienti per condividere i progressi nella consegna rispetto ai loro punti critici e ricevere feedback sulla roadmap.

Responsabilità

Abbiamo trattato gli strumenti di sviluppo come un prodotto customer-facing con contratti di servizio pubblicati. Abbiamo dimostrato responsabilità con email settimanali e aggiornamenti bisettimanali su tutti i prodotti. La trasparenza aiuta a costruire la fiducia dei clienti e mantiene il feedback fluido. 

Siamo stati in grado di fare progressi attraverso la misurazione, convalidare i miglioramenti attraverso la connessione con i clienti e dimostrare ai nostri clienti responsabilità con gli aggiornamenti. L’attenzione ha accelerato lo sviluppo e l’adozione di quattro innovazioni: Bazel (sistema di build), spazi di lavoro in cloud (ambiente di sviluppo), SnowCI (integrazione continua) e Snowfort (framework per test di regressione). Ciascuna delle quattro aree di innovazione ci ha consentito di superare le sfide tecniche e organizzative.

Bazel

I nostri sistemi di build legacy, Maven e CMake, avevano portato a una proliferazione di script di build e strumenti incoerenti, aumentando la curva di apprendimento per gli sviluppatori che lavorano con componenti diversi. Le build locali erano inaffidabili e richiedevano frequenti tentativi e build pulite per avere successo, il che provocava una forte frustrazione tra gli sviluppatori. Adottando Bazel, abbiamo ottenuto build coerenti, affidabili e veloci. Inoltre, l’esecuzione remota del backend su Buildbarn ci ha consentito di parallelizzare enormemente build e test, riducendo drasticamente la latenza.

Spazi di lavoro in cloud

Il vecchio ambiente di sviluppo sulle VM MacBook faticava a soddisfare la crescente domanda di creazione e test del prodotto. Gli utenti erano limitati a una sola VM attiva alla volta e il ripristino di una VM rotta poteva richiedere 30 minuti e talvolta molto più tempo. Per risolvere questo problema, abbiamo introdotto spazi di lavoro in cloud effimeri eseguiti su Kubernetes, precaricati con il codice dei punti di controllo più recenti, build in cache, IDE, strumenti di test e quant’altro serva all’utente per una produttività istantanea. L’utente può configurare uno spazio di lavoro in due minuti e gestire più spazi di lavoro in parallelo, con connessione rapida all’interno del data center direttamente alla cache di Bazel Buildbarn. 

La migrazione dell’ambiente di sviluppo è il cambiamento più rivoluzionario per i flussi di lavoro di sviluppo. Guidare l’adozione ha richiesto più di un ottimo prodotto per superare l’inerzia. Abbiamo fatto leva sugli early adopter come champion interni, abbiamo usato comunicazioni divertenti e creative per motivare i ritardatari, siamo andati team per team a mostrare i vantaggi e abbiamo chiuso il loop con feedback iterativi.

SnowCI

Storicamente, il nostro sistema CI era basato su script Jenkins eterogenei e disarticolati che erano cresciuti nel corso degli anni. Risolvere e ottimizzare questi problemi era complesso a causa delle scarse capacità di test e della limitata comprensione da parte dei team dell’intera configurazione del sistema. Creando internamente un sistema riprogettato da zero basato su YAML, chiamato SnowCI, per potenziare i nostri flussi di lavoro CI, abbiamo forzato la pulizia di questi script e siamo passati a un sistema CI molto più comprensibile, convenzionale e moderno. Questo ci ha consentito di misurare in modo coerente le fasi della CI, eliminare grandi porzioni di flussi di lavoro personalizzati e inaffidabili e concentrarci sulla velocità e l’affidabilità come nostri principi fondamentali.

Snowfort

Il nostro framework di test legacy è stato creato più di un decennio fa, senza isolamento per consentire l’inizio e la fine dei test in uno stato pulito, senza guardrail per evitare incoerenze e senza astrazioni per evitare la duplicazione del codice di configurazione boilerplate. Per questo abbiamo creato Snowfort, il framework per i test di regressione di Snowflake, per rimediare a queste carenze. Ci ha inoltre consentito di suddividere grandi risorse collaterali di test in piccoli lotti, consentendo di ripetere rapidamente i test con esito negativo. Buildbarn ci ha consentito di parallelizzare l’esecuzione dei test, riducendo la latenza CI. L’isolamento dei test ci ha consentito di ridurre drasticamente la flakiness dei test, migliorando l’affidabilità della CI.

Progressi

Tra febbraio e dicembre 2024, l’adozione dei quattro nuovi sistemi è passata dal 10-20% al 90-95%. La build è ora molto più affidabile e stabile con una latenza di otto minuti. La latenza e l’affidabilità della CI nelle diverse fasi della pipeline sono migliorate da tre a sei volte. Gli ambienti di sviluppo effimeri si attivano con build e strumenti completamente memorizzati nella cache in due minuti, preservando completamente le impostazioni tra le sessioni. Il framework Snowfort per i test di regressione semplifica la creazione di test affidabili con un corretto isolamento. Di conseguenza, il sentiment degli sviluppatori è notevolmente migliorato. In nove mesi, la percentuale di clienti interni insoddisfatti è scesa dal 58,9% al 21,4% e quella di clienti interni soddisfatti è passata dal 17,8% al 42,3%.

Il nostro lavoro non è finito. Abbiamo molto da fare per rendere le esperienze degli sviluppatori senza attrito e ancora più piacevoli. Stiamo investendo nella strategia Bazel e IDE per creare build locali in meno di un minuto ed esperienze di creazione e debug fluide per ogni linguaggio di programmazione in Snowflake. Stiamo investendo in SnowCI per completare le PR dall’authoring all’unione in meno di venti minuti. Con i quattro ingredienti chiave sopra menzionati, siamo ben posizionati per continuare a servire i nostri clienti.