Det er næsten fast rutine, at en ny leverandør eller udvikler finder den eksisterende kode dårlig, og det kan være sandt. Det er også det svar, der giver den største opgave, og nye udviklere foretrækker naturligt det, de selv har skrevet. Stil derfor tre spørgsmål, før I accepterer: Hvilket konkret problem kan I ikke løse i den nuværende kode? Hvad går tabt ved at lave om? Hvad kan klares gradvist? Holdbare grunde kan besvares ud fra jeres produkt og kunder. Smag kan ikke.
Hvorfor udsagnet er så almindeligt
Der er tre forklaringer, og de kan alle være på spil samtidig.
Den første er interesse. En omskrivning er en stor og overskuelig opgave, som leverandøren selv kan styre. At arbejde videre i andres kode er langsommere i starten og mere risikabelt for leverandøren.
Den anden er det, der kunne kaldes den nye læsers blik. Enhver kode ser rodet ud for den, der kommer udefra, fordi begrundelserne ikke kan ses. Mærkelige løsninger er ofte svar på rigtige problemer hos kunderne, som den nye endnu ikke kender.
Den tredje er, at det kan passe. Der findes kode, som ikke kan bære produktet længere. Derfor nytter det heller ikke at afvise udsagnet på rygraden. I skal have det efterprøvet.
Tre spørgsmål, der skiller grunde fra smag
Spørgsmål 1: Hvilket konkret problem skal omskrivningen løse? Bed om eksempler fra jeres produkt. “Funktion X kan ikke bygges, fordi data ligger sådan her” er en grund, som kan undersøges. “Koden er gammeldags”, “det er rodet” eller “vi plejer at bruge noget andet” er smag, indtil det er koblet til en konsekvens for kunder, sikkerhed, hastighed eller drift. Bed om tre konkrete eksempler og den vej, I går, hvis I lader koden stå.
Spørgsmål 2: Hvad mister I, og hvem bærer risikoen? Kode, der har kørt hos kunder, har indbygget mange små rettelser. Dem bygger en omskrivning ikke automatisk ind igen. Spørg: Hvordan sikrer I, at det, kunderne bruger i dag, stadig virker? Hvad sker der med ny funktionalitet, mens der skrives om? Hvor længe skal to versioner holdes kørende? Hvem betaler, hvis tidsplanen skrider? Et godt svar nævner datamigrering, altså flytningen af kundernes data over i det nye system. Mangler svaret, er opgaven ikke gennemtænkt.
Spørgsmål 3: Hvad kan klares gradvist? Det er sjældent alt eller intet. Ofte kan de værste dele udskiftes en ad gangen, mens produktet kører, se gradvis udskiftning i praksis. Bed leverandøren om at beskrive den gradvise vej og forklare, hvorfor den ikke kan bruges. Kan vedkommende ikke det, har forslaget ikke været vurderet ordentligt.
Sådan læser I svarene
Tegn på, at grunden holder:
- Leverandøren har læst koden og kan pege på bestemte steder.
- Forslaget nævner, hvad der kan genbruges.
- Der er taget stilling til data, kunder og overgang.
- Svaret ville være det samme, selv om en anden skulle lave arbejdet.
Tegn på smag eller interesse:
- Dommen faldt, før koden var læst ordentligt.
- Begrundelsen handler mest om teknologi, leverandøren foretrækker.
- Der er ingen plan for overgangen.
- Tilbuddet ligger allerede klar.
Spørg også, hvem der har lavet den vurdering, I har fået. Er det sælgeren eller en erfaren udvikler, der faktisk har læst koden?
Tænkt eksempel: En virksomhed med en fungerende SaaS skifter leverandør. Den nye anbefaler en fuld omskrivning, fordi rammeværket er gammelt. Da ledelsen spørger til konkrete problemer, viser det sig, at det kniber med ét område, nemlig rapporterne. Resten fungerer og kan opdateres. Opgaven krymper fra en omskrivning af hele produktet til en udskiftning af én del.
Hvis I stadig er i tvivl
Tre veje kan give mere sikkerhed.
Bed om en afgrænset prøve, hvor leverandøren retter eller bygger noget rigtigt i den nuværende kode. Så viser det sig, hvor galt det står, og I lærer leverandøren at kende.
Hent en vurdering fra en, der ikke får opgaven. Læs uafhængig gennemgang af koden, og vær tydelig med, at den, der vurderer, ikke må kunne vinde omskrivningen.
Sammenlign med jeres plan. Det store spørgsmål handler om, hvad I skal kunne de næste år. Selve overvejelsen har sin egen artikel, skal produktet skrives om?, og den tekniske gæld kan gøres synlig med sådan gør I teknisk gæld synlig.
Næste skridt er at sende de tre spørgsmål skriftligt til leverandøren og bede om svar, før I diskuterer pris og tid. Svaret afgør, om I står med en omskrivning, en gradvis plan eller blot en ny leverandør med en anden smag.
Det skal I lade være med
- At tage dommen for gode varer · den, der foreslår arbejdet, kan ikke være eneste dommer.
- At afvise alt på rygraden · nogle gange er koden faktisk for dårlig.
- At stoppe al ny udvikling på et løfte · kunderne venter ikke på en omskrivning.
- At bede om pris før begrundelse · så drejer samtalen sig om tilbuddet og ikke om behovet.
Det skal I kræve af den eksterne
- ☐ Vurdering af konkrete grunde med eksempler fra produktet.
- ☐ Afvejning af omskrivning mod gradvis forbedring.
- ☐ En plan for data, kunder og overgang, før noget besluttes.
- ☐ Ingen andel i det arbejde, anbefalingen fører til.
- ☐ En anbefaling skrevet til ledelsen.
Senest gennemgået: november 2026.
Næste skridt
Læs også: Skift af udviklingsleverandør uden at miste produktet · Teknisk gæld forklaret for ledelsen
→ Kontakt · Tlf. 70 13 63 23 · Ekstern CTO hos Nielco IT
