Teknologi og digitalisering

Teknisk gjeld

7. mars 2017

Teknisk gjeld er ikke noe nytt begrep, men i det siste har det vært litt buzz om det. Teknisk gjeld kan gi mange assosiasjoner, men overraskende lite er skrevet om dette, både generelt og akademisk. Enkelt sagt oppstår teknisk gjeld på grunn av dårlig kode.

Tall renner ned på animert hånd

Enkelt sagt oppstår teknisk gjeld på grunn av dårlig kode, som strengt tatt er fundamentet for det meste.

Ifølge Wikipedia er teknisk gjeld (som også kalles designkode) «… et begrep som gjenspeiler ekstra utviklingsarbeid som oppstår når man prioriterer å implementere kode som er enkel å implementere på kort sikt, fremfor den beste løsningen.» Begrepet ble skapt av Ward Cunningham, en programmerer som også er kjent for å utvikle den første wiki.

Et enkelt eksempel for å forklare teknisk gjeld er et prosjekt som står mellom to ulike løsninger. En er enkel å løse, men vil kreve tilpassing i fremtiden. Den andre løsningen har et bedre design, men er mer tidkrevende å løse. Hvis du velger den beste løsningen som er mer tidkrevende på kort sikt, vil du redusere fremtidige rentebetalinger.

Første gang jeg hørte om teknisk gjeld oppfattet jeg det som gjeld knyttet til «dårlige» IT-løsninger. For eksempel at virksomheten har investert tungt i IT-systemer som raskt blir utdatert. Eller at en bedrift velger et CRM- eller CMS på gale premisser, og investerer millioner av kroner i utvikling av disse – før de etter noen år ser at de har valgt feil system. Videre investering i systemer som skal avlaste administrasjonen, som viser seg å ikke fungere som ønsket – og som gjør at virksomheten ikke kan ta seg råd til ytterligere investeringer. Ikke minst at bedriften har investert i hardware og lokalt utstyr, og kanskje ikke vil ta seg råd til å flytte alt til smidige skybaserte løsninger. Dette er som kjent eksempel på hva som begynner å bli en problemstilling for mange bedrifter.

Dermed ble jeg overrasket da jeg leste at definisjonen av teknisk gjeld faktisk begrenser seg til dårlig kodekvalitet. Kanskje kunne Ward Cunningham valgt en bredere definisjon. Samtidig er alle systemer basert på nettopp koder, og koden er på mange måter grunnmuren i det meste; som når du bestiller varer på nett, betaler regninger i nettbanken, sjekker pris på en forsikring eller fordyper deg i en app på telefonen.

Overraskende mange ledere har ikke fått øynene opp for teknisk gjeld.

I dag er de fleste organisasjoner fullstendig avhengige av tekniske systemer, og de fleste er i gang med prosjekter hvor fokuset på teknologi er høyt (for teknologi er ikke mulig å komme foruten). Å skalere ned eller unngå teknisk gjeld blir fremover forretningskritisk for de fleste selskap, så hele ledergruppen bør ha forståelse for området – og sørge for at de ikke tar avgjørelser på gale premisser. Teknisk gjeld vil være en stor hemsko for forretningens videre utvikling, og det vil øke sjansen for å bli utsatt for disrupsjon.

Jeg skrev i en tidligere artikkel at en CDO etter min mening ikke skal forstå selve koden, det er andre i organisasjonen som skal kunne ta ansvar for kodekvaliteten. Hvordan dette skal henge sammen avhenger naturligvis av størrelsen på bedriften, type virksomhet, sammensetning av kompetanse i ledergruppen og nedover i organisasjonen. Koding kommer i mange former og varianter, og det blir mer og mer komplekst fremover. Eksperter på koding sitter ofte i konsulenthus, fordi de er avhengige av et godt fagmiljø. Alt det spennende som skjer innen virtual reality og robotics, eller wearable devices er for eksempel basert på koding. Det er en vanvittig fart innen teknisk utvikling, og alt er selvfølgelig basert på koder (og endring av dem).

Så hvordan kan du i store prosjekter med mange eksterne leverandører vite at kodekvaliteten er top notch? Litt av problemstillingen med at kodekvaliteten blir dårlig er nettopp at kunden presser på tid og leveranse, og utvikleren blir fristet til å ta snarveier for å komme i mål. For å sikre seg at koden blir god, har de fleste et ris bak speilet. En løsning er at leverandørene allerede i tilbudsprosessen blir orientert om at det vil være en uhildet part som skal sjekke kvaliteten i etterkant. Da er i hvert fall sjansen mye større for at prosjektet får suksess – og at virksomheten styrer unna potensiell teknisk gjeld.

You Might Also Like

No Comments

Legg inn en kommentar