Teknisk gjeld er et velkjent begrep for de fleste og brukes ofte som en betegnelse på hvor god helse koden har. Begrepet peker på de delene av en kodebase som ikke er av god kvalitet. Hensikten med å klassifisere disse delene er selvfølgelig at man senere skal komme tilbake å fikse opp i ugjerningen. Den klassiske måten å måle teknisk gjeld på er å lage en liste med punkter over kjent gjeld, for deretter å telle antall punkter på listen.
Hvis man tar innover seg gjeldsbegrepet så er det i praksis ikke gjelden, men rentene som kjennes på kroppen. Vi mener at det er mer hensiktsmessig å måle tekniske renter enn teknisk gjeld. Rentene kan man enkelt finne ved å se på differansen mellom hvor lang tid det tar å implementere en oppgave i et nyoppstartet utviklingsprosjekt i forhold til i forvaltning. Hvis man bruker 1 time på å lage en avkryssningsboks i nyutvikling og 8 timer i forvaltning, kan man regne med at 7 av disse timene er renter. Hastigheten man en gang hadde er nå redusert, differansen velger vi å se på som tekniske renter. Dette er tid som er lite nyttig og oppleves som frustrerende, tid som vi gjerne ønsker å bruke til noe annet.
I BEKK forvaltning har vi mange prosjekter med en hel del nedskrevet og noe glemt gjeld. Vi har undersøkt om vi kan måle de tekniske rentene på denne gjelden og om dette kan gi oss et bedre bilde av hvilke utfordringer vi står ovenfor. Målet er å kunne gjøre forvaltning av applikasjoner på en bedre måte.
Ved å notere når man betaler tekniske renter fant vi raskt ut hvilken størrelseorden gjelden var på. Samtidig ser vi i hvilken del av applikasjonen gjelden befinner seg. Delen med gjeld er den delen av systemet man jobber med når rentene betales. Grafen under viser hvordan vi ser for oss en slik rentebetaling gjennom utviklingsløpet. Hastigheten eller “Valuta for pengene” på y-aksen og tid langs x-aksen.
De faktorene vi har tatt for oss vil hver for seg senke utviklingshastigheten. Hver av faktorene peker på et området hvor vi betaler renter og derfor har teknisk gjeld. Det finnes mange flere punkter og de varierer selvfølgelig fra prosjekt til prosjekt. Dette er vår liste, du kan sikkert finne flere punkter vi hadde satt pris på om du legger de til i kommentarfeltet.
Figuren over viser at hvis man for eksempel mister fokus på å skape verdi så vil hastigheten synke over tid. Hvis man i tillegg mister overføring av kompetanse vil utviklingshastigheten reduseres ytligere på grunn av manglende kompetanse hos de som skal gjøre jobben framover. Konsekvensen av de ulike punktene akkumulerer slik at de totalt bidrar til en reduksjon av utviklingshastigheten.
Verdifokus
Prosjekter som har gått lenge har ofte en tendens til å bli preget av at prosjektet i bunn og grunn består i å rette feil. Det har tapt verdifokus i og med at man jobber med ting som ikke nødvendigvis gir mest verdi for pengene. I disse situasjonene har man ofte mistet overblikket og retningen for hvorfor prosjektet er i drift. Samtidig som koden man skriver blir vanskelig å vedlikeholde når de store linjene ikke tydelig kommer fram.
Kompetanse
Ofte ser vi prosjekter som sprinter mot lansering og i det prosjektet er ferdig går hele teamet over på nye prosjekter. Med de forsvinner også viktig kunnskap. Vi ser at ved å overlappe forvaltningsteamet med utviklingsteamet (dette kan gjøres på mange måter) slipper vi å gjenoppdage rutiner og konvensjoner. Tid man kan bruke på viktigere ting.
Automatiserte tester
Prosjekter av en viss alder har ikke automatiserte tester, eller tester i det hele tatt. Renter blir her betalt ved å opprette tester og regresjonstester for de delene av systemet hvor man skal gjøre endringer. Det å få tilbakebetalt disse rentene kan ta mye tid, men vi obsererer gang på gang at det er helt essensielt for at utviklinghastigheten skal øke.
Byggerutiner
Hvis noe gjør vondt, gjør det ofte. Hvis du gjør noe ofte, automatiser det. Det sier seg selv at slike oppgaver er repetitive, og hvis du gjør dem ofte tar de mye tid. Som igjen gjør at du bruker mye tid på å gjøre disse oppgavene.
Historie
Vi har i noen prosjekter brukt mye tid på å finne bakgrunnen for en designavgjørelse. I andre prosjekter har dette vært dokumentert ved god og uttrykksfull kode eller i form av en god og forståelig commit melding. Dette er steder hvor informasjonen er knyttet til kontekst (revisjon eller integrasjonspunkter) og hvis integrasjonspunktet endrer seg vil man med større sannsynlighet slette koden, i motsetning til dokumentet som omhandler det.
Hvert av punktene beskriver hvordan vi identifiserer at vi betaler renter og hvordan vi løste våre problemer. Det vi ønsker å få fram er ikke nødvendigvis størrelsen på den tekniske gjelden men hvordan man identifiserer den ved å se på betaling av renter. Ved å identifisere det vil man også være i en bedre posisjon for å ta problemet ved roten.
Denne posten er skrevet av 
