Teknisk gjeld kan gi mange assosiasjoner, men det er skrevet overraskende lite om det. Enkelt oppstår teknisk gjeld som følge av dårlig kode.
Ifølge Wikipedia er teknisk gjeld (som også kalles designkode) følgende. “… 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.
Skybaserte løsninger
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. Det investeres millioner av kroner i utvikling av CMS-et. Etter noen år innser selskapet at de har valgt feil system. Skal man investere videre i systemer som skal avlaste administrasjonen, som viser seg å ikke fungere? Det resulterer gjerne i at virksomheten ikke kan ta seg råd til ytterligere eller andre investeringer. Hva skjer hvis bedriften har investert i hardware og lokalt utstyr? Da har de kanskje ikke råd til å flytte til smidige skybaserte løsninger. Dette er et kjent eksempel på hva som begynner å bli en problemstilling for mange bedrifter.
Kodekvalitet
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. Koden er på mange måter grunnmuren i det meste. Eksempelvis 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.
Hemsko for selskapets utvikling
I dag er de fleste organisasjoner fullstendig avhengige av tekniske systemer. De fleste er i gang med prosjekter hvor fokuset på teknologi er høyt. Å skalere ned eller unngå teknisk gjeld blir fremover forretningskritisk for de fleste selskap. 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 potensielt være en stor hemsko for forretningens videre utvikling. Det vil videre øke sjansen for å bli utsatt for disrupsjon.
Mer og mer kompleks koding
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).
Ris bak speilet
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. Orienter leverandørene allerede i tilbudsprosessen om at en uhildet part vil 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.
