Etikk og bærekraft er et hett tema om dagen. Og med rette. I menneskehetens nyeste historie har vi hensynsløst forsynt oss både av naturressurser og menneskelige ressurser, og troen på «økonomisk vekst» er så godt innprentet at vi nærmest anser det for naturlov å være. Men hva har det med dårlig kode å gjøre?
Jeg har brukt en del tid på å studere FNs bærekraftsmål, ikke bare fordi det er et glimrende stykke strategiarbeid, men også fordi det er mye materie å reflektere over i sitt eget liv.
Så lurer du sikkert på: Hva kan bærekraftsmålene ha å si for vårt lille hjørne av rådgivningsbransjen?
Det er det jeg vil utforske her, med utgangspunkt i spørsmålet: Er det uetisk å skrive dårlig kode?
For det har seg sånn at datakraft åpenbart er en begrenset ressurs. Det samme er elektrisiteten og råmaterialene som skal til for at serverrommene våre skal fungere. Og som alle andre begrensede ressurser styres forbruket av prisen: Er det billig forbruker vi mye, er det dyrt, blir det relevant å se på kostnadsbesparende tiltak.
Innen IT har «CPU-kostnad» hittil vært et lite relevant tema for mange utviklere: Man skrev kode som virket, og man testet gjerne dataene sine en ekstra gang, bygget inn ekstra mekanismer, og så videre, for å være sikker på at koden fungerte etter hensikten.
Resultatet kunne bli at man skrev «uren» kode som var unødvendig komplisert, bare for å være sikker på at det fungerte, og følgelig «sløse» med ressursene. Men overforbruket av ressurser var ikke tydelige for den individuelle utvikler fordi CPU-kraft var et «fellesgode», og noe man i det aller fleste tilfeller hadde nok av. Ikke før noe gikk urimelig tregt, var det nødvendig å se på optimalisering.
Overforbruk av fellesressurser, hvor det ikke er noen åpenbar kostnad for den enkelte forbruker, eller utvikler, kalles «Allmenningens tragedie», som i økonomisk teori har opphav fra den gang bøndene lot buskapen beite på felles teig.
Innen deler av teknologi og utvikling har dog effektiv og god kode vært kritisk, og det var der det åpenbart forelå markedsmessige fortrinn å optimalisere kode. Eksempler på dette kan være spillindustrien, hvor en god grafikkopplevelse med (relativt) lite datakraft tilgjengelig ville gi produsenten en høyere inntekt.
I nyere tid er relevante eksempler utvinning av digital valuta (kryptovaluta), hvor lønnsomheten av utvinning er direkte knyttet til kostnaden av å utvinne den.
Videre har overgangen fra store On Premises-systemer til Software-as-a-Service-modeller, synliggjort kostnaden ved ineffektiv kode for den enkelte produsent.
Et eksempel fra vår egen bransje er at Microsoft Dynamics-produktene kommer fra tradisjonelle On Premises-systemer, hvor den enkelte kunde sørget for hardware, og drift av denne. Nå er de aller fleste implementeringer i Microsofts egne datasentre.
Parallelt har vi sett et enormt fokus på ytelse, diagnostiseringsverktøy og overvåkning knyttet til kode som yter dårlig. Dette er nok blant annet fordi Microsoft nå selv ser på egne resultatrapporter at det er store besparelser å hente ved å skrive om til mer effektiv kode, der man tidligere kan ha ligget på latsiden.
Likevel er det fortsatt ikke slik at den enkelte utvikler, som tross alt er de som tar de små, løpende beslutningene om utforming av koden, bærer noen direkte kostnad for ineffektiv kode. Derfor er det verdier som faglig stolthet i å skrive god, effektiv kode, som blir relevant. Videre også et fokus på at det er summen av alle enkeltutvikleres beslutninger, som utgjør den store helheten.
Så, hvordan kan et globalt bærekraftsmål implementeres i en rådgivnings- og utviklingsvirksomhet? Jo, det starter som alle andre endringsprosesser: med å innse at vi har en jobb å gjøre, og at vi er i posisjon til å styre det i riktig retning.
Å bevisst skrive dårlig kode for å ta den late veien, kan nesten sammenliknes med å kjøpe masse fast fashion-klær og kun bruke det én gang før det går i søpla.
Forslag til tiltak:
I Byx Digitals tjenestekonsept vil vi automatisk bli varslet dersom det er noe kode som yter under referanseverdier i våre kunders produksjonsmiljøer, som avstedkommer tilbakemeldinger til den ansvarlige utvikler, feilsøking og utbedring.