Episode 3: Teknisk gjeld

Det amerikanske forsvaret har gitt oss begrepet «defence readiness condition» — DEFCON.

Du kjenner det helt sikkert fra filmer du har sett.

Men hva har det med utvikling av programvare å gjøre?

Hei, Martin her, og du lytter til Fimbul!

Høsten 1959 laget det amerikanske forsvaret en skala som skulle fortelle noe om spenningsnivået i en konflikt og hvilket beredskapsnivå man måtte ha for å være ovenpå situasjonen.

Skalaen heter DEFCON og er godt kjent fra diverse krigsfilmer. Den går fra 5 — som er det laveste beredskapsnivået — til 1 som er krig — med maksimal beredskap og umiddelbar respons.

Siden skalaen ble utviklet etter andre verdenskrig, har man naturlig nok aldri sett DEFCON 1. Det høyeste man har vært er DEFCON 2 under Cuba-krisen høsten 1962, hvor atomkrig var nært forestående.

For å visualisere skalaen, har den fargekoder. Fra DEFCON 5 som er det laveste nivået med blått, via grønn, gul, rød til hvit.

DEFCON har heldigvis liten relevans til vår egen hverdag, men den har en metafor og et element man kan bruke som et enkelt styringsverktøy i hverdagen.

Heldigvis slipper vi å forholde oss til den globale spenningen eller internasjonale konflikter i hverdagen. Vi som arbeider med teknologi har nok spenning med de løsningene vi har ansvaret for til daglig.

Har du jobbet lenge nok med teknologi, har du garantert opplevd nedetid. Utilsiktet nedetid. Når noe går galt og trekker alt med seg i dragsuget. Alt går ned og ingen vet hvorfor.

Tidligere jobbet jeg som konsulent, og jeg husker spesielt godt en periode hvor jeg jobbet for en kunde med masse fysiske butikker som du som lytter garantert har besøkt.

Under dette prosjektet leverte vi blant annet programvaren til kassene og i perioder opplevde vi masse nedetid. Å stå i kassen når kassesystemet ikke fungerer og køen med kunder vokser, var stressende og ubehagelig. Samtidig var det også svært lærerikt.

I dag har jeg produktansvaret for en av de større IT-løsningene i Norge. Rett før jul hadde vi vår mest omfattende nedetid i løsningens historie. Vi var fullstendig nede i et par timer, og kundeservice ble nedringt av frustrerte kunder.

I motsetning til nedetiden jeg refererte til som konsulent, var nedetiden før jul mindre stressende, av flere årsaker. Først og fremst fordi det selvfølgelig ikke stod en kø av kunder som ikke fikk betalt, men også fordi tidligere erfaringer har lært oss hvordan man skal forberede seg for katastrofer. Stress og mas og kjefting løser absolutt ingenting.

Nøkkelen ligger i systematiske forberedelser og øvelser. Nedetiden kommer. Alle vet det. Alle forventer det. Når det er forventet er det langt enklere å arbeide systematisk med rutiner og prosedyrer for hva man gjør når nedetiden kommer.

Risikovurdering er et av våre viktigste verktøy, og inngår i vårt totale arbeid med informasjonssikkerhet. Risiko er produktet av sannsynlighet og konsekvens. Hva er sannsynligheten for at noe skjer, og hva er konsekvensen når det inntreffer?

Hver gang vi lager ny funksjonalitet, starter vi alltid med risikovurdering. Det vi skal i gang med nå, hva kan gå galt? Hva kan vi miste? Denne innsikten dokumenterer vi og tar med oss inn i utviklingsarbeidet. Dermed er det enklere å utvikle løsningen for å unngå det som ikke skal skje, for eksempel datalekkasjer eller nedetid. Vi får snakke mer om risikovurdering og informasjonssikkerhet i en senere episode.

Over tid utvikler man stadig mer funksjonalitet. Gammel kode kjører, ny kommer til. Flere applikasjoner. Flere databaser. Flere programmeringsspråk. Utviklere kommer, utviklere går.

Man opparbeider seg det man kaller teknisk gjeld.

Teknisk gjeld kan ses på som den størrelsen av en IT-løsning som gir høyere risiko for feil enn hva man har akseptert å tåle.

Teknisk gjeld er dårlig skrevet kode som noen bare skulle få fort ut og så fikse senere, men som aldri blir gjort, typisk fordi man skal rekke en frist.

Teknisk gjeld er løsninger som ikke blir oppgradert og patchet.

Teknisk gjeld er summen av alt som hemmer oss fra å gjøre annet, produktivt arbeid.

Teknisk gjeld gir oss merarbeid, det gir oss manuelle prosesser, det gir oss stress og det gjør oss umotiverte. Ingen gidder å jobbe med løsninger hvor man bruker mesteparten av tiden på å holde skuta flytende, fremfor å lage nye kule ting.

Samtidig er det viktig å anerkjenne at man alltid vil ha teknisk gjeld i sine løsninger. Det er alltid noe som burde vært gjort eller kunne vært gjort. Programvare som skulle vært oppgradert. Kode man skulle ferdigstilt.

Og det er helt greit.

Det er helt greit å utsette arbeid som burde vært gjort, fordi man vet at det er den beste prioriteringen akkurat nå. Risikoen er akseptabel. Det er ikke kritisk.

Alternativet til teknisk gjeld kalles «gold plating», og er en tilstand hvor man aldri får levert fra seg sitt arbeid fordi man sitter og ruger på det til det er perfekt. Det er heller ikke en tilstand man vil være i.

På kontoret har hvert utviklingsteam et barometer. En liten viser man kan vri på foran en fargelagt skala. Parallellen kjenner vi fra DEFCON.

En gang i uken stiller utviklingsteamet på barometeret i fellesskap. Hvordan føler vi den totale kvaliteten på løsningene vi har ansvaret for er? Hvordan er magefølelsen min når jeg går inn døren til kontoret om morgenen? Er den myk og fin, eller er den hard og litt stram? Gleder jeg meg til å gå på jobb eller gruer jeg meg? Er jeg motivert eller er jeg lei?

Vanskeligere trenger det ikke være. Det fine er at alt tar seg løse. Det er «bare» teknologi. Vi kan fikse det. Det er opp til oss. Ingen andre.

Det er bortkastet tid å prøve å måle teknisk gjeld maskinelt. Snakk heller med dem som arbeider med løsningene og drifter dem hver dag.

Sørg for at folkene dine har det bra, og har de ikke det må du prioritere å bruke tid på at de skal få det.

Tusen takk for at du lytter til Fimbul, vi høres!