Lagom i koden: när "tillräckligt bra" faktiskt är rätt beslut

En av de största utmaningarna för en passionerad mjukvaruutvecklare är strävan efter perfektion. Många ingenjörer känner en yrkesstolthet i att bygga det mest eleganta, avancerade och framtidssäkra systemet som världen någonsin har skådat. Man vill refaktorera koden, bygga in oändlig skalbarhet och använda de allra senaste ramverken. Men i den svenska affärsvärlden krockar detta ofta med landets mest djupgående filosofi: Lagom. Att applicera "lagom" på sin kod är ofta skillnaden mellan en utvecklare som bara skriver vacker text, och en Senior utvecklare som förstår affärsvärde.

Fällan med Overengineering

Överarbetning (Overengineering) är en av de dyraste synderna på en IT-avdelning. Det uppstår när en utvecklare bygger ett system som är alldeles för komplext för det problem som egentligen ska lösas. Ett klassiskt exempel: Företaget ber dig bygga en enkel intern databas för hundra anställda att logga sina semesterdagar i. Istället för att slänga upp en enkel lösning, tillbringar du en månad med att bygga en globalt distribuerad, AI-driven mikro-arkitektur som klarar tio miljoner användare per sekund.
Du kanske är stolt över din kod, men ur ett affärsperspektiv har du misslyckats. Du har slösat företagets tid och pengar på att bygga något som aldrig kommer att användas fullt ut. Du har inte varit lagom. Du har varit extrem.

YAGNI – You Aren't Gonna Need It

Den svenska kulturen präglas av pragmatism – att vara praktisk, effektiv och lösningsorienterad. Inom systemutveckling finns det en princip som passar den svenska mentaliteten perfekt: YAGNI (You Aren't Gonna Need It). Den säger att du aldrig ska skriva kod eller bygga funktioner för att du kanske kommer behöva dem i framtiden. Du ska bygga exakt det som behövs för att lösa det nuvarande problemet. Om framtiden förändras, ändrar du koden då. Att försöka förutspå framtiden i kod leder nästan alltid till komplicerad spagettikod som ingen förstår, och funktioner som ligger och samlar damm.

MVP-kulturen och "Tillräckligt bra"

På svenska startups är mantrat nästan alltid att snabbt få ut en MVP (Minimum Viable Product). En MVP är själva definitionen av lagom. Den är inte perfekt, den saknar många funktioner och designen kanske inte är helt polerad. Men den fungerar, och den löser kundens grundläggande problem.
Varför älskar svenskar MVP:er? För att vi hellre vill ha användarnas (kundernas) feedback snabbt, än att sitta i ett stängt rum i två år och bygga något som vi gissar är perfekt. En "tillräckligt bra" produkt som lanseras idag är alltid mer värd än en perfekt produkt som lanseras om två år. Om du ständigt vägrar släppa ifrån dig din kod för att du vill refaktorera den "en gång till för att den ska bli perfekt", kommer du att bromsa hela teamets leverans. I Sverige hyllar vi leverans framför perfektionism.

Den tekniska skulden (Technical Debt)

Finns det då inte en risk med att bygga saker för snabbt och för "lagom"? Jo, den stora risken kallas Teknisk skuld. När vi tar genvägar, skriver snabb och lite slarvig kod för att hinna till en deadline, lånar vi tid från framtiden. Precis som med ett banklån, måste denna skuld betalas tillbaka med ränta. Om koden är ett lapptäcke av snabba lösningar kommer det snart bli omöjligt att lägga till nya funktioner utan att hela systemet kraschar.

Här kommer den sanna konsten i svenskt tech-ledarskap fram: Balansgången. En pragmatisk, senior utvecklare vet när det är dags att bygga snabbt för att lansera en MVP (ta på sig skuld), och när det är dags att stoppa all nyutveckling och spendera en vecka på att refaktorera (skriva om och städa upp) koden för att betala av skulden. De vågar säga till produktägaren: "Vi byggde detta snabbt (lagom) förra månaden för att testa marknaden. Marknaden älskade det. Nu måste vi stanna upp och bygga om grunden innan huset rasar."

Underhållbarhet är det ultimata målet

Att skriva lagom kod betyder i slutändan att du skriver underhållbar (maintainable) kod. Du skriver inte kod för att visa hur smart du är. Smart, extremt avancerad kod (clever code) är ofta oerhört svår för nästa person att läsa. Du skriver kod för den stackars juniora kollegan (eller dig själv om sex månader) som ska behöva fixa en bugg i ditt system på en fredagskväll. Enkel, tydlig, väl namngiven och tråkigt logisk kod är den bästa koden. Den är lagom. Och den är grunden till ett hållbart, stressfritt och framgångsrikt svenskt IT-företag.