Vi hadde brukere som ventet på daglige dataoppdateringer. Orkesteringsverktøyet Dagster kunne løse det elegant med: flott UI, god debugging, oversikt over avhengigheter. Men det ville ta uker å sette opp ordentlig.
Så jeg valgte GitHub Actions og Python-scripts i stedet. Funksjonaliteten kom på plass på dager.
Dette valget minnet meg om noe Henry David Thoreau skrev i 1854. Han flyttet til skogen ved Walden-innsjøen, bygde en enkel hytte og levde der i to år. Hans tilnærming var radikal enkel: et solid fundament, vegger som holdt været ute, et enkelt tak. Hytta var liten, men den ga ham alt han trengte for å komme i gang.
Etterhvert demret det for meg at problemene jeg jobbet med hadde en del til felles med de som beskrives i Thoreaus bok.
Problemet med prematur kompleksitet
La meg ta deg med inn i et konkret prosjekt. Jeg jobbet med å hente verdifull innsikt fra mange ulike datasett. Mitt første instinkt var å planlegge den perfekte dataplattformen. Moderne verktøy, bleeding edge-teknologi, skalerbar for alle tenkelige behov flere år frem i tid.
Sammenhengen til boken slo meg: I min metaforiske hytte hadde jeg planlagt å installere gulvvarme uten å ha et ferdig tak. Jeg leverte ingen verdi til brukerne, og det ble stadig vanskeligere å vise at tiden jeg brukte ville lønne seg.
Tilbake til grunnleggende
Jeg endret kurs. Istedenfor å bygge den perfekte plattformen, startet jeg med innsiktsarbeid:
Hva ønsker brukerne faktisk å vite?
Hvilken data har vi allerede tilgjengelig?
Hvor får vi mest verdi med minst innsats?
Resultatet? Et dashboard brukerne faktisk trengte, levert på dager istedenfor uker. Datainnhenting, kvalitetssjekker og orkestrering kunne komme senere.
Hvem tjener hvem?
Utover i prosjektet så brukerne verdien av dashboardene. De begynte å ta mer datadrevne beslutninger. Naturlig nok kom nye ønsker: Daglige oppdateringer, robuste kvalitetssjekker, mer automatisering.
Samtidig leste jeg Thoreaus kritikk av jernbanen på 1800-tallet. Den skulle bringe folk sammen, gjøre livet enklere. Men Thoreau mente noe annet: Mennesker har blitt altfor avhengige av teknologien de selv hadde bygd.
Han stiller seg selv spørsmålet: Hvem tjener hvem?
Vi som data engineers bør stille samme spørsmål. For hver teknologi vi legger til stacken, betaler vi ikke bare lisensen. Vi betaler med:
- Onboarding av nye teammedlemmer
- Debugging på fredagskvelden
- Mental overhead av enda et system å holde oversikt over
Dette er den virkelige kostnaden av kompleksitet.
Dagster-dilemmaet
I prosjektet var jeg i ferd med å gå i samme felle som boken beskriver. Dagster, et orkestreringsverktøy som kunne håndtere datakvalitetssjekker, datainnhenting og transformasjoner. Med Dagster ville jeg fått et elegant brukergrensesnitt for å følge flyten, enklere debugging når noe går galt, og bedre oversikt over avhengigheter mellom jobber.
Men det har en pris.
Å sette opp Dagster ordentlig tar tid. Ikke bare installasjonen, men å strukturere koden riktig, konfigurere schedules, definere assets og ops. Det betyr mer kompleksitet i stacken før vi i det hele tatt har levert ny funksjonalitet til brukerne. Og hver gang noen nye skal jobbe med plattformen, er det enda et verktøy de må sette seg inn i.
Så jeg stilte spørsmålet: Hvem tjener hvem?
I dette øyeblikket, med brukere som ventet på daglige oppdateringer, ville Dagster tjene meg mer enn brukerne. Jeg ville få et flottere oppsett å vise frem, bedre verktøy for feilsøking senere. Men brukerne ville måtte vente uker lengre på funksjonaliteten de trengte nå.
Istedenfor utvidet jeg verktøy vi allerede hadde:
- Python-script for jevnlig datainnhenting i Azure
- GitHub Actions for transformasjoner med integrert CI/CD
Funksjonaliteten kom på plass i løpet av dager. Er løsningen like elegant som med Dagster? Nei. Kommer vi til å trenge Dagster senere når kompleksiteten vokser? Sannsynligvis.
Når ville jeg valgt Dagster? Når vi hadde 20+ daglige jobber med komplekse avhengigheter, eller når debugging tok timer hver uke. Da ville investeringen lønne seg.
Men da tar vi den diskusjonen, når verdien av bedre orkestrering faktisk oppveier kostnaden.
To prinsipper jeg tar med meg videre
1. Kan dette løses på en enklere måte?
Thoreau levde spartansk, men dekte alle sine grunnbehov. Han identifiserte hva han virkelig trengte for å trives og fokuserte på det. Resten var støy.
Jobben som data engineer er lik. Vi må avdekke de reelle behovene og finne de enkleste måtene å levere disse til brukerne. Ofte kan behovene dekkes med enkle verktøy vi allerede har. Kompleksiteten kan komme senere, når den faktisk trengs.
Man er ikke lat når man starter enkelt. Man respekterer brukernes tid.
2. Velg det kjedelige, strategisk
Thoreau valgte skogen fremfor Boston. Stillhet fremfor selskap. Vi kan også velge det kjedelige fremfor det spennende, men det må være et bevisst valg.
En stor del av stacken din bør være kjedelig. For de delene av plattformen som bare skal fungere, velg det etablerte og stabile. Men vær smart med hvor du eksperimenterer.
Hvis bedriften skal slå konkurrentene på sanntidsanbefalinger, da er moderne streaming-teknologi verdt investeringen. Hvis differensieringen ligger i ML-modeller, invester der.
Nøkkelen er å vite forskjellen: Kjedelig og stabilt for fundamentet. Spennende og innovativt der det faktisk flytter nåla for forretningen.
Mot til å velge mindre
Thoreau forlot skogen etter to år fordi han, som han skrev, hadde flere liv å leve. Men prinsippene hans om enkelhet forblir relevante.
Å velge mindre er det modigste valget. Det krever mot å si nei. Det krever selvtillit å utfordre bransjens antakelser. Det krever klokskap til å skille mellom hva som er spennende og hva som skaper verdi.
Neste gang noen foreslår å legge til et nytt verktøy i stacken: Still Thoreaus spørsmål. Hvem tjener hvem?