Fyra skäl att skriva om kod som fungerar, och ett skäl att låta bli

De flesta omskrivningar av fungerande kod tjänar utvecklaren, inte verksamheten. Innan du river en applikation som gör sitt jobb behöver du kunna peka på ett affärsvärde: säkerhet, personberoende, en mätbar kostnadskurva eller en förmåga koden aldrig byggdes för. Saknas alla fyra handlar det om smak och smak är ett dyrt skäl att lägga tre månaders utveckling på något som redan levererade. Precis den här iakttagelsen är utgångspunkten i Anatoliy Babushkas resonemang om varför de flesta omskrivningar gynnar utvecklaren snarare än verksamheten.

Det räcker med att förstå grundprincipen. Kod som körts i produktion i flera år är inte en belastning, den är en journal. Varje konstigt villkor, varje udda timeout och varje `if` som ser felaktig ut är oftast en fix för en incident som någon redan har haft. Skriver du om alltihop kastar du den kunskapen och börjar samla på dig samma buggar från noll.

En utvecklare bytte CakePHP mot Laravel och verksamheten märkte ingenting

Ett konkret mönster ser ut så här. En utvecklare tar en fungerande applikation byggd i CakePHP och skriver om den i Laravel, delvis på egen tid, utan att någon bett om det. När arbetet är klart gör appen exakt samma jobb, för samma användare, i samma hastighet. Det enda som blev bättre var hur koden kändes för den som skrev den.

Det är precis det som händer när ett tekniskt val förväxlas med ett affärsbeslut. Omskrivningen godkändes i efterhand, nästa projekt startades också i Laravel och affärsfallet gjordes aldrig. Ingen frågade vad det kostade i utebliven feature-utveckling under tiden eller vad organisationen fick tillbaka.

Frågan att ställa är enkel: vad kan verksamheten göra efter omskrivningen som den inte kunde före? Blir svaret ”ingenting men koden är trevligare” har du hittat ingenjörsmässig egoism, inte ett projekt.

De fyra fallen där omskrivning faktiskt betalar sig

Det finns lägen där en omskrivning är rätt beslut och de har det gemensamt att någon annan än utvecklaren blir hjälpt.

Runtime eller ett nyckelberoende är end-of-life med öppna säkerhetshål. Kör du på en PHP-, Node- eller Python-version som inte längre får säkerhetsuppdateringar och det finns öppna CVE:er utan uppgraderingsväg, då är risken konkret och mätbar. Här skriver du inte om av smak utan för att stänga en dörr som annars står öppen mot produktionsdata.

En enda person förstår systemet och den personen har just sagt upp sig. Ett system som bara lever i ett huvud är en risk oavsett hur bra koden är. När det huvudet går ut genom dörren blir en kontrollerad omskrivning eller åtminstone en genomgripande dokumentation, billigare än att sitta med en svart låda ingen vågar röra.

Varje ny feature kostar tre gånger vad den borde och trenden går att mäta. Det här är det starkaste ekonomiska argumentet, för det syns i siffror. Om leveranstiden per funktion stiger stadigt månad för månad betalar systemet redan ett pris. En omskrivning blir då en investering med en avkastning du kan räkna på, inte en känsla av att koden är ”gammal”.

Verksamheten behöver en förmåga som koden aldrig designades för. En monolit byggd för en handfull användare per dag klarar inte tiotusen per minut hur mycket du än lappar. När kravet flyttat sig bortom det ursprungliga syftet är ombyggnad ibland enda vägen.

Lägg märke till att inget av de fyra fallen handlar om vilket ramverk som är modernast eller vad som ser bra ut i en intervju.

Problemet är sällan disciplin, det är att beslutet aldrig skrevs ner

Standish Groups återkommande CHAOS-mätningar visar att ungefär 31 procent av IT-projekt levereras i tid och inom den ram som från början definierades. Resten glider.

Arbetsbeskrivningen undertecknas och arkiveras, sedan glider den ifrån det faktiska arbetet.

Det är sällan lathet. Det är att dokumentet som skulle styra projektet läggs i en mapp och sedan lever sitt eget liv medan koden lever sitt. Ett typiskt scenario: vid vecka tre står det fem sidor i beskrivningen men femton i det faktiska projektet, utan att någon spårar var skillnaden kom ifrån. Forskning från Handelshögskolan vid Karlstads universitet har pekat på liknande dolda skulder i systemutveckling, där kostnader byggs upp utan att synas i budgeten.

Kopplingen till omskrivningar är direkt. Om ingen skrev ner varför omskrivningen skulle göras, finns det heller inget att stämma av mot när den drar iväg. Affärsfallet är inte byråkrati, det är det enda som skiljer ett motiverat projekt från ett dyrt hobbybygge.

Ny teknik skapar inte värde bara för att den är installerad

Samma fälla dyker upp på fler ställen än i omskrivningar. Många organisationer har dashboards, loggar, mätvärden och larm på plats, ibland flera övervakningsplattformar parallellt men saknar en tydlig riktning för vad allt ska användas till. Verktyget är implementerat men värdet uteblir eftersom ingen bestämde vad det skulle svara på.

Principen är densamma oavsett om det gäller ett nytt ramverk eller ett nytt observabilitetsverktyg: tekniken levererar inte automatiskt affärsvärde bara för att den finns. Beslutet måste kunna förklaras för någon som inte skriver koden. Klarar det inte det testet är det inte moget att genomföras.

Ett bra sätt att hålla sig ärlig är att skriva ner det förväntade värdet innan man börjar, precis som man säger upp en AI-prenumeration när den slutar löna sig. Utan en förväntan att mäta mot finns inget sätt att avgöra om projektet lyckades.

FAQ

När är det direkt fel att skriva om fungerande kod?

När det enda argumentet är att koden är gammal, att ramverket är omodernt eller att den nuvarande lösningen känns fel. Ålder är ingen bugg. Kod som körts stabilt i produktion i åratal har bevisat sig och en omskrivning kastar bort alla incidentfixar som byggts in över tid.

Räcker det inte att modernisera i stället för att skriva om?

Ofta räcker det och det är oftast billigare. Uppgradera runtime, byt ut ett enskilt beroende, bryt ut en modul som verkligen behöver ändras. En fullständig omskrivning är rätt först när problemet ligger i själva arkitekturen och inte går att lappa stegvis.

Hur mäter jag att en feature blivit tre gånger dyrare?

Följ ledtiden per funktion över tid, alltså hur länge det tar från beslut till driftsatt kod. Ser du en stadig ökning över flera månader, samtidigt som teamet inte förändrats, har du ett mätbart tecken på att systemet självt bromsar arbetet. Den kurvan är ett starkare argument än vilken smakåsikt som helst.

Nästa gång någon föreslår en omskrivning, be om att få se de fyra frågorna besvarade innan en enda rad kod rivs. Går ingen av dem att svara ja på med siffror, är svaret att låta den fungerande koden fortsätta fungera.