Både privat og offentlig sektor er glad i å snakke om bærekraft, selv om vi kanskje har mistet litt fokus de siste månedene. Fortsatt skal årsrapporter, visjoner og presentasjoner krydres pent med løfter om redusert karbonfotavtrykk eller til og med karbonnøytralitet.
Noen team blir også pålagt å rapportere karbonutslipp, som ikke bare enkelt hvis man har mange og komplekse applikasjoner.
På mange områder i samfunnet har tiltak og verktøy blitt ganske konkrete. Veiing av matavfall, sensorer og timere for å redusere energiforbruk i kontorbygninger og smart-grids og bærekraftig byplanlegging er noen eksempler.
Reagerer på nye AI-krav: – Krever hundrevis av ganger mer energi
Jeg som utvikler har derimot ikke mange opplagte eller etablerte verktøy som hjelper meg med bevissthet rundt dette i hverdagen.
Det hjelper ikke så mye om jeg spiser opp all maten min i kantinen, kildesorterer plasten i en egen bøtte med blått merke eller bruker den lille spyleknappen på do hvis jeg samtidig trekker inn en npm-pakke på 100kb i appen min som lastes ned av brukere 2 millioner ganger i måneden.
Det gir omtrent 200 GB ekstra nedlastet hver måned hvis vi ser bort ifra caching! Gang det med X antall team som gjør det samme i X antall apper, så snakker vi noen gode kilo CO2e.
Hvordan begynner vi?
Det er med bærekraft som med universell utforming eller innebygget personvern: Vi må ville det, vi må gidde og vi må ha en forståelse for hvordan vi angriper dette som et samlet team.
Det holder ikke med én idealist i teamet hvis resten lukker ørene - da skjer det lite.
- Kognitiv forståelse: Alle utviklere VET at ekstra kode stort sett gir økt størrelse på nedlasting av appen eller nettsiden, men ikke alle har et bevisst forhold til regnestykket som til slutt ender i et CO2e-estimat.
- Teknologivalg og karbonkostnad: Bruk av ferdige npm-pakker er ikke bare en bekvemmelighet og en tidsbesparelse - det har også en karbonkostnad.
- Droppe direktiver og bestemmelser: Alle vet at dersom en utvikler ikke skjønner poenget eller ikke er enig, så blir ikke ting gjort. Utviklerne må forstå sammenhengen og se effekten av reduksjonene de har fått til.
Så mye utslipp skaper koden din: «Mye er rent sløseri»
Måling og monitorering
Det er vanskelig å sette opp regnestykker som presist regner ut karbonavtrykk til enhver tid. Riktignok har skyleverandører verktøy som lar meg overvåke estimert karbonutslipp i forbindelse med lagring og behandling av data, men dette inkluderer stort sett ikke energibruk ved nettverksøverføring eller på brukeres egne enheter.
Derimot kan teamet kan måle endringer i metrikker fra en versjonering til den neste, eller ved registrering av en ny PR.
Metrikker som total laststørrelse, Largest Contentful Paint, Total Duration of Long Tasks, Total Requests er noen metrikker som enkelt kan måles med verktøy som Lighthouse eller Sitespeed.
Jeg mener at det ikke noe poeng å forsøke å måle nøyaktig karbonutslipp fra dag til dag - det er tidkrevende regnestykker å vedlikeholde, vanskelig å gjøre nøyaktig og gir liten mening i hverdagen. Da er det bedre å måle endringer i kjørende kode feks ved hver prodsetting. Hvis flere av metrikkene viser at ting går i feil retning over en periode, er det kanskje på tide å ta tak og grave mer i hva som skjer?
– Bransjen lukker øynene i jakten på inntekter
Daglige kommunikasjonskanaler
Det hjelper dessuten lite med flott grafikk og fete Grafanaboards hvis ingen holder øye med dem.
Vi bør sende målingene og rapportene inn i de kanalene som teamet bruker i det daglige, enten det er Slack, Teams eller morsekode.
Varsler om metrikk-endringer som kan påvirke karbonutslipp bør varsles like tydelig som “critical warnings” fra Sentry eller UU-varsler fra Siteimprove.
Men viktigst av alt uansett er vilje i teamet. Teamet må ha en felles forståelse for sammenhengen mellom teknologivalg og bærekraft, og ha lyst til å gjøre noe med det. Hvis slike ting bare kommer fra toppen uten forankring nedover blir dette nok en rapport som ligger i skuffen til sjefen og støver ned.
