Bygge systemet om eller videreudvikle det?

Når et system begynder at knirke, dukker det samme spørgsmål altid op: Skal vi skrive det hele om fra bunden eller fortsætte med at bygge på det vi har? Få tekniske beslutninger er så følelsesladede. Begge lejre har gode argumenter, og begge har forudsigelige blinde vinkler. Her er den tankegang der hjælper dig med at træffe beslutningen på baggrund af fakta i stedet for frustration.

Derfor frister en total omskrivning

Udviklere der arbejder i en gammel kodebase, ser dens værste sider hver dag: rodet struktur, forældede afhængigheder, simple ændringer der tager uger. Tanken om at starte forfra med ren arkitektur og moderne teknologi er oprigtigt fristende.

Men vær opmærksom på den sammenligning der bliver lavet. Den der foreslår en omskrivning, stiller et virkeligt system med alle dets ar op mod et tænkt system som endnu ikke har mødt virkeligheden. Det nye ser altid bedre ud på whiteboardet end det gamle gør i produktion.

Derfor bliver omskrivninger systematisk undervurderet

To mekanismer gør at omskrivninger næsten altid bliver større end planlagt.

Skjult forretningslogik. Et system der har kørt i ti år, har samlet tusindvis af små beslutninger: specialregler for en bestemt kundetype, håndtering af særtilfælde med datoer, undtagelser der blev tilføjet efter en hændelse. Det meste er udokumenteret og kan kun ses i koden. Den nye version skal genskabe alt dette for at forretningen kan fungere, men i kalkulen tæller som regel kun de funktioner der er synlige på overfladen.

Second system-effekten. Når teamet endelig får lov at bygge nyt, vil man rette alle gamle fejl og tilføje alt det man har savnet, på én gang. Version to bliver derfor gang på gang mere ambitiøs end nogen egentlig har bestilt: større scope, længere projekt, højere risiko.

Oven i det kommer dobbeltarbejdet. Forretningen kan sjældent fryse udviklingen i et eller to år, så hver ny funktion skal bygges i både det gamle og det nye system. Ellers er det nye forældet allerede ved lanceringen.

Trinvis modernisering er det rigtige udgangspunkt

For de fleste systemer er grundanbefalingen derfor at videreudvikle og modernisere trinvis: forbedre koden indefra, udskifte den mest problematiske del først og lade resten leve videre bag stabile grænseflader.

• Værdien kommer løbende. Hver udskiftet del forbedrer hverdagen med det samme i stedet for at al værdien ligger i slutningen af et flerårigt projekt.
• Risikoen er afgrænset. Går et trin galt, påvirkes én del af systemet og ikke hele forretningen på én gang.
• Kursen kan ændres. Prioriteterne kan justeres mellem etaperne efterhånden som forretningen lærer hvad der giver effekt.
• Forretningslogikken bevares. Den skjulte logik flyttes stykke for stykke og verificeres mod det gamle systems adfærd i stedet for at blive genopfundet i ét hug.

Når en total omskrivning faktisk er begrundet

Der findes situationer hvor trinvis modernisering ikke rækker. De er færre end man tror, men de er virkelige:

Opfylder systemet ét eller flere af kriterierne, er en omskrivning værd at undersøge seriøst. Gør den alligevel så begrænset som muligt: Genskab det der faktisk bruges, ikke alt der nogensinde er bygget.

Bias-advarslen gælder begge veje

Omskrivningsiveren er den mest almindelige fælde, men det modsatte findes også. Den der har investeret år i et system, vil nødig acceptere tanken om at det har udspillet sin rolle, og så bliver det lappet videre længe efter at regnestykket er holdt op med at gå op. Hvis vedligeholdelsen æder størstedelen af udviklingsbudgettet, hvis hver release kræver manuel akrobatik og hvis ingen tør røre visse dele af koden, så er “vi fortsætter som vi plejer” ikke det trygge valg. Det er bare det tavse.

Sådan træffer du beslutningen i praksis

Tag et konkret eksempel: en grossistvirksomhed med et ordresystem bygget i 2012. Systemet fungerer, men platformen nærmer sig slutningen af sin livscyklus, og to nøgleudviklere nærmer sig pensionsalderen. I stedet for at vælge mellem “behold det hele” og “skriv det hele om” kortlægger virksomheden systemet i dele. Integrationerne flyttes først til et moderne mellemlag, derefter udskiftes kundeportalen, og kernen, den prislogik der fungerer, får lov at leve videre bag et stabilt API indtil også den kan erstattes.

Resultatet er en plan hvor hver etape har sit eget budget, sin egen værdi og et punkt hvor man kan holde pause uden at stå med et halvfærdigt byggeri. Sådan kommer du ud af et knirkende system uden at satse alt på ét kort.

Vil du have en second opinion på jeres vejvalg? Hos Weapp laver vi den her type teknisk kortlægning som en del af vores ydelser. Kontakt os, så ser vi på forudsætningerne sammen.