Modernisera gammal programvara utan en stor omskrivning

Nästan varje etablerat företag har ett: en programvara som alla tyst ogillar. Den är långsam, den är ful, halva teamet känner till en kringgång för buggen som ingen någonsin fixade, och den enda person som förstod den slutade 2019. Instinkten är alltid densamma — bränn ner den och bygg en ny. Och den instinkten är, oftare än inte, precis hur bra företag förlorar ett år och en liten förmögenhet på ingenting.

Jag har sett den stora omskrivningen gå fel tillräckligt många gånger för att ha en reflex kring det. En grundare visar mig sitt knakande ordersystem eller sitt urgamla schemaläggningsverktyg, suckar och säger någon version av ”vi behöver bara byta ut hela grejen”. Och kanske gör ni det en dag. Men den fullständiga omskrivningen — riv ut det gamla systemet, bygg ett glänsande nytt parallellt, slå om en strömbrytare — är ett av de mest riskabla dragen i hela mjukvaruvärlden. Det är dyrt, det tar mycket längre tid än utlovat, och under hela tiden kör ni blint och hoppas att det nya täcker varje konstigt specialfall som det gamla tyst hanterade i femton år.

Den goda nyheten är att den storskaliga omskrivningen nästan aldrig är det enda alternativet, och sällan det bästa. Det finns ett lugnare sätt att modernisera — stegvis, återställbart och skonsamt mot verksamheten som fortfarande måste tjäna pengar medan ni arbetar. Detta är en guide till det sättet: hur du avgör vad som faktiskt behöver fixas, hur du byter ut de smärtsamma delarna utan att ta ner hela systemet, och hur du vet när en fullständig omskrivning verkligen är rätt beslut.

Varför den storskaliga omskrivningen är så lockande — och så farlig

Den fullständiga omskrivningen är förförisk eftersom den lovar ett rent bord. Inget mer äldre röra, inga fler kompromisser, en färsk kodbas byggd på rätt sätt med moderna verktyg. På en whiteboard ser det självklart ut. I verkligheten skriver du på för att bygga om år av ackumulerad affärslogik — mycket av den odokumenterad, en del lever bara i huvudet på folk som har slutat — medan klockan tickar och räkningarna kommer in.

Den djupare fällan är parallelluniversum-problemet. Under de månader eller år det tar att bygga ersättaren har du två system: det gamla, som fortfarande måste driva verksamheten, och det nya, som inte är klart än. Varje ändring verksamheten behöver måste göras två gånger, annars hamnar det nya systemet efter verkligheten innan det ens lanseras. Team bränner ut sig på att hålla båda vid liv. Och eftersom ingen får byta över förrän det nya systemet gör allt, blir det ingen tidig vinst, ingen feedback, inget bevis på att det fungerar — bara en lång, ängslig väntan på en enorm allt-eller-inget-lanseringsdag.

Det finns en välkänd branschsägen här, och den är välförtjänt: det andra systemet, den stora omskrivningen, har en vana att ta tre gånger så lång tid som beräknat och anlända med färre funktioner än det den ersätter. Uppskattningen är inte fel för att folk är slarviga. Den är fel för att ingen kan se, vid starten, alla de små saker som det gamla systemet tyst gör rätt.

Vad ”äldre” faktiskt betyder (det handlar inte om ålder)

Vi slänger oss med ordet äldre som om det bara betyder gammalt. Det gör det inte. Massor av programvara som har körts i ett decennium är helt okej — tråkig, stabil, betald, gör sitt jobb. Ålder i sig är ingen anledning att röra något. Det dyraste misstaget i hela det här fältet är att modernisera något som tyst fungerade, bara för att det såg daterat ut.

Programvara förtjänar etiketten äldre när den aktivt står i vägen för dig. När du inte tryggt kan ändra den eftersom ingen förstår den fullt ut. När den inte kan koppla upp sig mot verktygen du nu är beroende av. När en enda person är den enda som kan hålla den vid liv. När den är så långsam eller skör att ditt team har byggt upp en hel folktradition av kringgångar runt den. Det är den verkliga definitionen — inte året den skrevs, utan kostnaden den ålägger dig idag och risken den bär in i morgondagen.

Ställ diagnos innan du rör något

Innan en enda rad skrivs om behöver du en ärlig karta över var smärtan faktiskt bor. Oftast är systemet som alla hatar 80 procent okej. Bekymret är koncentrerat till ett fåtal specifika ställen — en långsam vy, en trasig integration, ett arbetsflöde som tvingar fram dubbel datainmatning — och de få ställena genererar nästan alla klagomål. Hitta dem, så har du hittat hela ditt projekt.

Sättet att hitta dem är inte en teknisk granskning först — det är ett samtal. Sätt dig med människorna som använder grejen varje dag och fråga var det skaver. Var väntar de? Vad skriver de in på nytt? Vad undviker de för att det är jobbigt? Var håller de ett privat kalkylark för att kringgå det officiella systemet? Dessa kringgångar är guld: var och en är en exakt röntgenbild av ett problem värt att fixa.

• Vyerna och stegen folk klagar mest på — inte i teorin, utan i deras faktiska dagliga arbete.
• Varje ställe där data matas in två gånger för att två system inte pratar med varandra.
• Integrationerna som gick sönder, eller aldrig fanns, och tvingar fram manuell kopiering mellan verktyg.
• Allt som bara en person vet hur man hanterar eller fixar — dina enskilda felkällor.
• De delar som faktiskt är okej, så att du kan skydda dem och låta dem vara.
• Vad verksamheten kommer att behöva nästa år som det nuvarande systemet helt enkelt inte kan växa in i.

När du gör det här ärligt krymper projektet oftast. Ägaren som klev in och sa ”byt ut allt” går ut och inser att de behöver fixa tre saker. Det är ingen besvikelse — det är en lättnad. Tre fixbara saker är ett projekt du kan slutföra detta kvartal. En fullständig ersättning är ett år du kanske inte överlever.

Strangler-metoden: byt ut den en bit i taget

Det finns ett mönster för att göra detta tryggt, och det har ett lite dystert men minnesvärt namn: strangler-metoden, efter strypfikuset — en lian som växer runt ett träd och gradvis tar över dess struktur tills den nya tillväxten till slut står på egna ben och den gamla stammen är borta. Tillämpat på programvara är idén vackert praktisk: du byter inte ut det gamla systemet i ett enda heroiskt byte. Du odlar det nya runt det, en bit i taget, tills det inte finns något kvar av det gamla som någon behöver.

I praktiken fungerar det så här. Du väljer en smärtsam bit — säg faktureringsmodulen som alla hatar. Du bygger en modern ersättare för just den biten. Du dirigerar faktureringen till den nya modulen medan allt annat fortsätter köra på det gamla systemet, orört. Du bevakar den ett tag. När den är stabil tystnar den delen av det gamla systemet, och du går vidare till nästa bit. Det gamla systemet krymper gradvis, som ett ljus, istället för att rivas ner på en gång.

Det som gör detta så mycket tryggare än en omskrivning är att varje steg är litet, levande och återställbart. Du kör aldrig blint. Varje ny bit kommer snabbt i verklig användning, så du får snabbt veta om den faktiskt fungerar. Om något går fel har du bara riskerat en modul, inte hela verksamheten — och du kan oftast falla tillbaka till den gamla vägen medan du fixar den. Du får vinster längs vägen istället för en skräckinjagande lansering i slutet. Och verksamheten fortsätter köra, som vanligt, hela tiden.

Hur rytmen faktiskt ser ut

1. 1
   Välj den mest smärtsamma, mest fristående biten

   Du vill ha hög smärta och rena kanter — en modul som gör väldigt ont och inte har fingrarna i allt annat. Det är ditt första mål.
2. 2
   Lägg ett tunt lager framför det gamla systemet

   Ett litet dirigeringslager avgör vilka förfrågningar som går till det gamla systemet och vilka som går till den nya biten. Det är fogen som gör allt annat möjligt.
3. 3
   Bygg och lansera bara den ena biten

   Byt ut en modul, få ut den i verkliga händer och dirigera bara den skivan av arbetet till den. Veckor, inte år — och resten av systemet rörde sig aldrig.
4. 4
   Stabilisera, gå sedan vidare till nästa bit

   När den nya modulen är betrodd går den matchande delen av det gamla systemet i viloläge. Upprepa med nästa smärtsamma bit, och lär dig längs vägen.
5. 5
   Pensionera det gamla systemet när det är tomt

   Till slut gör det äldre systemet ingenting som någon förlitar sig på. Först då stänger du av det — tyst, utan dramatik, eftersom allt viktigt redan har flyttat.

Lägg märke till vad som är annorlunda från omskrivningen: det finns ingen enda lanseringsdag att frukta. Det finns inget parallelluniversum att underhålla. Det nya systemet är i produktion från vecka tre, drar in sitt och lär dig saker, istället för att vänta i ett labb på en lansering som hela tiden skjuts upp.

Ibland behöver du inte ens byta ut den

Innan du byter ut något alls är det värt att fråga om det gamla systemet behöver bytas ut eller bara behöver sluta vara en ö. Ett förvånande antal ”vi behöver ett nytt system”-problem är egentligen ”våra system pratar inte med varandra”-problem. Den gamla programvaran är bra på sitt jobb — den sitter bara i en silo och tvingar folk att frakta data in och ut för hand.

I de fallen är den billigaste, snabbaste lösningen inte ett nytt system. Det är en bro. Du sveper in den gamla programvaran i en koppling — en integration som låter den utbyta data med dina andra verktyg automatiskt — och ett modernt lager ovanpå för de delar folk faktiskt rör vid. Den daterade motorn fortsätter surra under; teamet får en ren yta och ett slut på kopiera-klistra. Det är inte glamoröst, men det är ofta den högsta avkastningen per euro i hela arbetet.

När en fullständig omskrivning verkligen är rätt beslut

Jag har ägnat hela den här guiden åt att tala dig ur den stora omskrivningen, så låt mig vara rättvis: ibland är den faktiskt svaret. Det finns grunder som är så ruttna att ingen mängd lappning, broar eller bit-för-bit-byte räddar dem, och att låtsas annat skjuter bara upp det oundvikliga medan du lägger pengar på att stötta upp ett lik.

De ärliga tecknen är specifika. Tekniken systemet är byggt på är död eller döende — inget stöd, inga säkerhetsuppdateringar, ingen kvar som kan arbeta med den. Verksamheten har förändrats så grundläggande att den gamla modellen inte längre alls stämmer med verkligheten. Eller så är systemet så trasslat att även små ändringar rutinmässigt går sönder på orelaterade ställen, vilket oftast betyder att det inte finns några rena fogar att göra en strangler-metod i från första början. När två eller tre av dessa är sanna samtidigt slutar det stegvisa arbetet vara det tryggare valet.

Och här är den tysta belöningen av att göra det stegvisa arbetet först, även om du till slut bygger om: när du väl kommer dit förstår du systemet långt bättre än du gjorde i början. Varje modul du bytte ut lärde dig något som de ursprungliga författarna aldrig skrev ner. En omskrivning informerad av den kunskapen är ett helt annat, långt tryggare djur än den som lanserades på dag-ett-optimism.

Delen ingen nämner: det handlar mest om människor

Här är något de tekniska guiderna hoppar över. Den svåraste delen av att modernisera gammal programvara är oftast inte koden — det är människorna som har ägnat år åt att anpassa sig till den. De känner dess egenheter. De har muskelminne för dess konstiga genvägar. En ny modul som objektivt är bättre kan ändå kännas sämre de första två veckorna, helt enkelt för att den är obekant. Om du ignorerar det kan även en perfekt teknisk migrering misslyckas.

Den stegvisa metoden hjälper även här, nästan av en slump. Eftersom förändringen kommer en liten bit i taget tar folk till sig den gradvis istället för att ombes lära om allt på en enda måndagsmorgon. Ta in de dagliga användarna tidigt. Låt dem forma ersättaren innan den är klar. Teamet som hjälpte till att designa den nya faktureringsvyn kommer att försvara den; teamet som fick den i knät kommer att ogilla den, även om den är identisk. Modernisering är ett förändringsledningsprojekt utklätt till mjukvara.

Vanliga frågor