Elsker du 'technical debt'?

Technical debt findes i din forretning, uden du ved det. Eller måske du ved det, men vil ikke gøre noget ved det?

Af Kristian Just Iversen

Snakker du om ’technical debt’ med dine kolleger?

Til de uindviede – ’technical debt’ (teknisk gæld) referer til kode eller dele af et projekt, der mangler at blive ’gået efter i sømmene’ og optimeret. Det kan skyldes, at koden ikke er blevet vedligeholdt løbende, eller at det er gået for stærkt, at det blev skrevet i første omgang. Eller at der simpelthen bare blev truffet forkerte beslutninger, da projektet blev udviklet, så man nu står med nogle suboptimale funktioner eller suboptimal projektstruktur.

Men har du nogensinde hørt dine kolleger eller din projektleder snakke om ’technical debt’?

Har du selv 'technical debt' i kode, som du har ansvaret for, men har været lidt langsom til at gøre noget ved det?

Kan man se ’technical debt’?

Ingen regel uden undtagelse - men som regel kan man ikke se det. Og det skyldes, at de synlige dele af et projekt, som mangler at blive vedligeholdt, vil den projektansvarlige altid slå ned på først. Disse dele er nemlig nemme at identificere, og alle er enige om, at det ikke gør noget godt for slutkundens forretning, hvis en funktion ikke opfører sig efter hensigten.

Synlige fejl eller nye funktioner, vil den projektansvarlige næsten altid prioritere. Og skal det gå stærkt med at få udviklet et projekt færdig op til en deadline, bruges der ikke time efter time i mødelokalet med ens kolleger for at fastlægge den mest optimale projektstruktur. Så produceres der på de synlige dele, som man ved, den projektansvarlige vil have færdig.

Hvad koster ’technical debt’?

Selvom ‘technical debt’ typisk er usynlig suboptimal kode, så kan man ikke bare være ligeglad. For suboptimal kode koster.

Som navnet antyder, er det et slags “lån”. Du skriver dele af projektet hurtigere, for at spare tid nu og her. Men du skal betale det tilbage på et senere tidspunkt. Hvis du har tid senere, er det jo fint. Så giver det god mening at få skubbet et projekt udover stepperne.

Ligger du derimod altid under pres i din forretning, så lad være at bilde dig selv ind, at du pludselig om 6 måneder får tid til at rette det kode, du ikke havde tid til at skrive rigtigt første gang.

Du opbygger gæld - og du betaler renterne hver dag:

• Den suboptimale kode kan i sig selv nemt betyde flere fejl i systemet.
• Den suboptimale kode bliver svær at videreudvikle på.
• Den suboptimale kode kan gøre det sværere at opdatere den øvrige kode.
• Når den suboptimale kode endelig skal optimeres (den tekniske gæld tilbagebetales), har alle glemt, hvilke genveje man tog i sin tid, og hvordan koden burde have været skrevet

Med andre ord - alt bliver mere tidskrævende og risikoen for fejl øges => meromkostning til dig, dit firma eller din kunde.

Jeg vil gerne undgå ’technical debt’ – hvad gør jeg?

At opbygge en midlertidig ‘technical debt’ kan i nogle tilfælde give mening. Men hvis det ikke lyder tiltalende for dig, er her et par tips til at undgå det (bare rolig, det lyder heller ikke tiltalende for mig):

• Hvis du er programmør: Vær ikke bange for at sige, at du har kode, du mangler at følge op på. Det er efter min mening meget mere professionelt, at du viser, at du faktisk går op i, at det du har afleveret, bør være i orden, end at den projektansvarlige senere finder fejl eller hører fra andre, at det kode du har skrevet, ikke er godt nok. Og du kommer ikke uden om det under nogen omstændigheder - så få det hellere rettet før som senere.
• Hvis du er projektansvarlig: Giv plads til at lade programmørerne optimere strukturen. Alt handler ikke om at få udført den ene delopgave efter den anden. Der er også et overordnet sammenhæng i koden, som der skal afsættes tid til. Spørg dit programmeringsteam, om de vil have 1 dag i den nærmeste fremtid, til at følge op på kode, som de ønsker at gøre bedre. Gentag øvelsen jævnligt, indtil programmørerne ikke længere har brug for tid til optimering.
• Hvis du er programmør, og har en uforstående projektansvarlig: Det hjælper tit, at snakke til pengepungen. Forklar den projektansvarlige, at ‘technical debt’ dukker op, når tingene går for stærkt. At de nu har fået en masse funktioner lynhurtigt, og skal kvittere med lidt tid til at tilbagebetale den tekniske gæld.
• Hvis du er programmør: forfald aldrig til at lave ‘den hurtige løsning’. Man har aldrig nogensinde i programmeringens levetid sparet noget som helst i sidste ende. Lav det rigtigt første gang, og sov godt i weekenden.
• Hvis du er projektansvarlig, men har en programmør, der ikke går op i god kode og projektstruktur: Forsøg at engagere programmørerne til at gå op i god kode. Vær med til at skabe en kultur, hvor kvaliteten af arbejdet er vigtigere end at få udviklet flest mulige funktioner. Eller hvis det ikke lykkedes, så find en ny programmør, som går op i din forretning (ved ikke at opbygge teknisk gæld).

Er det programmøren eller den projektansvarlige, der har skylden?

Det er altid programmøren eller softwarearkitekten, der laver ‘technical debt’ i første omgang. Det kan være forårsaget af omstændighederne, men i sidste ende, er det et valg de, der har indflydelse på kodens struktur, tager.

Det kan ske, fordi programmøren ikke får sagt “nej”. “Den her funktion vil vi vildt gerne have op at køre hurtigst muligt, tror du, du kan presse den ind?” - tør du sige “nej, jeg vil lige finpudse koden lidt i stedet”? Den er svær at sælge ind, men med tiden forstår man vigtigheden af, altid at være up-to-date og undgå gæld.

Det kan også ske, når projektets pris skal forhandles. Her kan det direkte kræves af kunden, at der skal laves hurtige løsninger, der ikke skal skrives dokumentation el.lign. I forbindelse med udvikling af prototyper, giver dette god mening. Ellers ikke, og programmøren bør gør opmærksom på dette og forklare kunden om konsekvenserne ved suboptimal projektstruktur og teknisk gæld generelt.

TL;DR

Teknisk gæld koster penge, besværliggør videreudvikling og ikke mindst: giver programmøren og kunden grå hår. Det bør undgås i første omgang, men sniger teknisk gæld alligevel sig ind (det gør det), så må der afsættes tid til at få samlet op. Tør sig det højt, og alle bliver mere tilfredse med projektets nyvundne stabilitet.