Modernisér gammel programvare uten en stor omskriving

Nesten hver etablerte bedrift har en: en programvare som alle stille misliker. Den er treg, den er stygg, halve teamet kjenner en omvei til feilen ingen noensinne rettet, og den ene personen som forsto den, sluttet i 2019. Instinktet er alltid det samme — brenn den ned og bygg en ny. Og det instinktet er, oftere enn ikke, akkurat slik gode selskaper taper et år og en liten formue på ingenting.

Jeg har sett den store omskrivingen gå galt nok ganger til å ha en refleks rundt det. En gründer viser meg sitt knirkende ordresystem eller sitt eldgamle planleggingsverktøy, sukker og sier en versjon av «vi trenger bare å bytte ut hele greia». Og kanskje gjør dere det en dag. Men den fulle omskrivingen — riv ut det gamle systemet, bygg et skinnende nytt parallelt, vri om en bryter — er et av de mest risikable grepene i hele programvareverdenen. Det er dyrt, det tar langt lengre tid enn lovet, og hele tiden kjører dere i blinde og håper at det nye dekker hvert rare grensetilfelle som det gamle stille håndterte i femten år.

Den gode nyheten er at den store omskrivingen nesten aldri er det eneste alternativet, og sjelden det beste. Det finnes en roligere måte å modernisere på — trinnvis, reverserbar og skånsom mot virksomheten som fortsatt må tjene penger mens dere jobber. Dette er en guide til den måten: hvordan du avgjør hva som faktisk må fikses, hvordan du bytter ut de smertefulle delene uten å ta ned hele systemet, og hvordan du vet når en full omskriving virkelig er det riktige valget.

Hvorfor den store omskrivingen er så fristende — og så farlig

Den fulle omskrivingen er forførende fordi den lover blanke ark. Ikke mer eldre rot, ingen flere kompromisser, en frisk kodebase bygget riktig med moderne verktøy. På en tavle ser det opplagt ut. I virkeligheten skriver du under på å bygge om år med oppsamlet forretningslogikk — mye av den udokumentert, noe lever bare i hodet på folk som har sluttet — mens klokka tikker og regningene kommer inn.

Den dypere fellen er paralleluniverset-problemet. I de månedene eller årene det tar å bygge erstatteren, har du to systemer: det gamle, som fortsatt må drive virksomheten, og det nye, som ikke er klart ennå. Hver endring virksomheten trenger, må gjøres to ganger, ellers sakker det nye systemet bak virkeligheten før det i det hele tatt lanseres. Team brenner ut på å holde begge i live. Og fordi ingen får bytte over før det nye systemet gjør alt, er det ingen tidlig seier, ingen tilbakemelding, ingen bevis på at det virker — bare en lang, engstelig venting på én enorm alt-eller-ingenting-lanseringsdag.

Det finnes en velkjent bransjefortelling her, og den er fortjent: det andre systemet, den store omskrivingen, har for vane å ta tre ganger så lang tid som anslått og ankomme med færre funksjoner enn det den erstatter. Estimatet er ikke feil fordi folk er skjødesløse. Det er feil fordi ingen ved starten kan se alle de små tingene som det gamle systemet stille gjør riktig.

Hva «eldre» faktisk betyr (det handler ikke om alder)

Vi slenger rundt oss med ordet eldre som om det bare betyr gammelt. Det gjør det ikke. Massevis av programvare som har kjørt i et tiår, er helt fin — kjedelig, stabil, betalt, gjør jobben sin. Alder alene er ingen grunn til å røre noe. Den dyreste feilen i hele dette feltet er å modernisere noe som stille fungerte, bare fordi det så datert ut.

Programvare fortjener merkelappen eldre når den aktivt står i veien for deg. Når du ikke trygt kan endre den fordi ingen forstår den fullt ut. Når den ikke kan koble seg til verktøyene du nå er avhengig av. Når én enkelt person er den eneste som kan holde den i live. Når den er så treg eller skjør at teamet ditt har bygget en hel folklore av omveier rundt den. Det er den virkelige definisjonen — ikke året den ble skrevet, men kostnaden den påfører deg i dag og risikoen den bærer inn i morgendagen.

Still diagnosen før du rører noe

Før en eneste linje skrives om, trenger du et ærlig kart over hvor smerten faktisk bor. Som regel er systemet alle hater 80 prosent greit. Problemet er konsentrert på noen få bestemte steder — én treg skjerm, én ødelagt integrasjon, én arbeidsflyt som tvinger fram dobbel dataregistrering — og de få stedene genererer nesten alle klagene. Finn dem, og du har funnet hele prosjektet ditt.

Måten å finne dem på er ikke en teknisk gjennomgang først — det er en samtale. Sett deg med folkene som bruker greia hver dag, og spør hvor det gjør vondt. Hvor venter de? Hva taster de inn på nytt? Hva unngår de fordi det er plagsomt? Hvor holder de et privat regneark for å omgå det offisielle systemet? De omveiene er gull: hver enkelt er et presist røntgenbilde av et problem verdt å fikse.

• Skjermene og trinnene folk klager mest på — ikke i teorien, men i deres faktiske daglige arbeid.
• Hvert sted der data tastes inn to ganger fordi to systemer ikke snakker sammen.
• Integrasjonene som gikk i stykker, eller aldri fantes, og tvinger fram manuell kopiering mellom verktøy.
• Alt som bare én person vet hvordan man betjener eller fikser — dine enkeltpunkter for svikt.
• De delene som faktisk er greie, så du kan beskytte dem og la dem være.
• Hva virksomheten vil trenge neste år som dagens system rett og slett ikke kan vokse inn i.

Når du gjør dette ærlig, krymper prosjektet som regel. Eieren som kom inn og sa «bytt ut alt», går ut og innser at de trenger å fikse tre ting. Det er ingen skuffelse — det er en lettelse. Tre fiksbare ting er et prosjekt du kan fullføre dette kvartalet. En full utskifting er et år du kanskje ikke overlever.

Strangler-metoden: bytt den ut én bit om gangen

Det finnes et mønster for å gjøre dette trygt, og det har et litt dystert, men minneverdig navn: strangler-metoden, etter kvelerfikenen — en slyngplante som vokser rundt et tre og gradvis overtar strukturen, helt til den nye veksten til slutt står på egne ben og den gamle stammen er borte. Anvendt på programvare er ideen vakkert praktisk: du bytter ikke ut det gamle systemet i ett heroisk bytte. Du dyrker det nye opp rundt det, én bit om gangen, til det ikke er noe igjen av det gamle som noen trenger.

I praksis fungerer det slik. Du velger én smertefull bit — si fakturamodulen alle hater. Du bygger en moderne erstatter for bare den biten. Du ruter faktureringen til den nye modulen mens alt annet kjører videre på det gamle systemet, urørt. Du følger med på den en stund. Når den er solid, blir den delen av det gamle systemet stille, og du går videre til neste bit. Det gamle systemet krymper gradvis, som et stearinlys, i stedet for å bli revet ned på én gang.

Det som gjør dette så mye tryggere enn en omskriving, er at hvert steg er lite, levende og reverserbart. Du kjører aldri i blinde. Hver nye bit kommer raskt i reell bruk, så du finner raskt ut om den faktisk virker. Hvis noe går galt, har du bare risikert én modul, ikke hele virksomheten — og du kan vanligvis falle tilbake til den gamle veien mens du fikser den. Du får seire underveis i stedet for én skremmende lansering til slutt. Og virksomheten kjører videre, som normalt, hele tiden.

Hvordan rytmen faktisk ser ut

1. 1
   Velg den mest smertefulle, mest selvstendige biten

   Du vil ha høy smerte og rene kanter — en modul som gjør mye vondt og ikke har fingrene i alt annet. Det er ditt første mål.
2. 2
   Legg et tynt lag foran det gamle systemet

   Et lite rutingslag avgjør hvilke forespørsler som går til det gamle systemet og hvilke som går til den nye biten. Det er sømmen som gjør alt annet mulig.
3. 3
   Bygg og lansér bare den ene biten

   Bytt ut én modul, få den ut i ekte hender, og rut bare den delen av arbeidet til den. Uker, ikke år — og resten av systemet flyttet seg aldri.
4. 4
   Stabilisér, gå så videre til neste bit

   Når den nye modulen er til å stole på, går den tilsvarende delen av det gamle systemet i dvale. Gjenta med den neste smertefulle biten, og lær underveis.
5. 5
   Pensjonér det gamle systemet når det er tomt

   Til slutt gjør det eldre systemet ingenting noen er avhengig av. Først da slår du det av — stille, uten dramatikk, fordi alt viktig allerede har flyttet.

Legg merke til hva som er annerledes fra omskrivingen: det finnes ingen enkelt lanseringsdag å frykte. Det finnes ikke noe paralleluniverse å vedlikeholde. Det nye systemet er i produksjon fra uke tre, tjener sitt eget og lærer deg ting, i stedet for å vente i et laboratorium på en lansering som stadig glipper.

Noen ganger trenger du ikke engang å bytte den ut

Før du bytter ut noe som helst, er det verdt å spørre om det gamle systemet trenger å byttes ut eller bare trenger å slutte å være en øy. Et overraskende antall «vi trenger et nytt system»-problemer er egentlig «systemene våre snakker ikke sammen»-problemer. Den gamle programvaren er fin til jobben sin — den sitter bare i en silo og tvinger folk til å frakte data inn og ut for hånd.

I de tilfellene er den billigste, raskeste løsningen ikke et nytt system. Det er en bro. Du pakker den gamle programvaren inn i en kobling — en integrasjon som lar den utveksle data med de andre verktøyene dine automatisk — og et moderne lag på toppen for de delene folk faktisk tar på. Den daterte motoren durer videre under; teamet får en ren overflate og en slutt på kopier-lim-inn. Det er ikke glamorøst, men det er ofte den høyeste avkastningen per euro i hele innsatsen.

Når en full omskriving virkelig er det riktige valget

Jeg har brukt hele denne guiden på å snakke deg vekk fra den store omskrivingen, så la meg være rettferdig: noen ganger er den faktisk svaret. Det finnes fundamenter som er så råtne at ingen mengde lapping, broer eller bit-for-bit-utskifting redder dem, og å late som noe annet utsetter bare det uunngåelige mens du bruker penger på å støtte et lik.

De ærlige tegnene er spesifikke. Teknologien systemet er bygget på, er død eller døende — ingen støtte, ingen sikkerhetsoppdateringer, ingen igjen som kan jobbe med den. Virksomheten har endret seg så grunnleggende at den gamle modellen ikke lenger passer til virkeligheten i det hele tatt. Eller systemet er så sammenfiltret at selv små endringer rutinemessig ødelegger ting på urelaterte steder, noe som vanligvis betyr at det ikke finnes rene sømmer å gjøre en strangler-metode i fra start. Når to eller tre av disse er sanne samtidig, slutter det trinnvise arbeidet å være det tryggere valget.

Og her er den stille gevinsten av å gjøre det trinnvise arbeidet først, selv om du til slutt bygger om: når du kommer dit, forstår du systemet langt bedre enn du gjorde i starten. Hver modul du byttet ut, lærte deg noe de opprinnelige forfatterne aldri skrev ned. En omskriving informert av den kunnskapen er et helt annet, langt tryggere dyr enn den som ble lansert på dag-én-optimisme.

Delen ingen nevner: det handler mest om mennesker

Her er noe de tekniske guidene hopper over. Den vanskeligste delen av å modernisere gammel programvare er som regel ikke koden — det er menneskene som har brukt år på å tilpasse seg den. De kjenner særhetene dens. De har muskelminne for de rare snarveiene dens. En ny modul som objektivt er bedre, kan likevel føles verre de første to ukene, rett og slett fordi den er ukjent. Hvis du ignorerer det, kan selv en perfekt teknisk migrering mislykkes.

Den trinnvise metoden hjelper også her, nesten ved et uhell. Fordi endringen kommer én liten bit om gangen, tar folk den til seg gradvis i stedet for å bli bedt om å lære alt på nytt en enkelt mandag morgen. Ta de daglige brukerne inn tidlig. La dem forme erstatteren før den er ferdig. Teamet som var med på å designe den nye fakturaskjermen, vil kjempe for den; teamet som fikk den slengt i fanget, vil mislike den, selv om den er identisk. Modernisering er et endringsledelsesprosjekt forkledd som programvare.

Vanlige spørsmål