Varför mjukvara aldrig blir rätt (och det är okej)

Mjukvara blir sällan rätt första gången. Det beror inte på att man kodar fel saker, utan på att du inte kan veta vad "rätt" är förrän du sett hur produkten används i verkligheten.

När vi byggde ChainSec fastnade vi till exempel mycket i perfektionismfällan i början. Vi övertänkte detaljer och specialfall som kanske aldrig skulle inträffa. Vi gissade också mycket på vad vi trodde att kunderna ville ha.

När vi äntligen lanserade till våra första användare så visade det sig att de behövde något helt annat än det vi byggt. Vi hade alltså spenderat veckor på att lösa problem som inte existerade.

Varför perfektionism bromsar dig

Många utvecklare har perfektionistiska drag, ofta manifesterade genom extrem noggrannhet med kodstruktur, variabelnamn och prestanda.

För existerande lösningar är detta sällan ett problem, för någon har sagt till dig vad användarna behöver. Men när man bygger ny mjukvara – särskilt i en startup – ser det helt annorlunda ut. Då rör du dig på oupptäckt mark, där du inte kan veta exakt vad som krävs förrän du prövat och fått återkoppling.

Det kanske fortfarande känns som god ingenjörskonst. Men det är ofta slöseri med tid.

Problemet med att sträva efter perfektion från start är att du inte kan veta vad perfekt betyder förrän du sett hur produkten används. Du bygger baserat på antaganden. Och antaganden är nästan alltid fel.

Tänk på det: hur många gånger har du byggt något, lanserat det, och sedan insett att användarna behöver något helt annat? Hur ofta har dina ursprungliga abstraktioner varit fel när du väl förstår problemdomänen?

Om du tidigare har byggt MVPs och nya produkter är svaret "nästan alltid".

Att lansera tidigt är viktigare än perfekt kod

För att vara tydlig: det handlar inte om att medvetet skriva dålig kod, utan om att det alltid är bättre med kod som faktiskt körs i produktion än perfekt kod som aldrig når användarna.

Andra gången man bygger om en vy eller funktion, efter att du fått återkoppling från användare, går det nästan alltid snabbare och bättre. Inte för att man plötsligt blivit skickligare programmerare, utan för att man har data. Man vet vilka funktioner som faktiskt används, förstår användarnas arbetsflöde och har sett de verkliga prestandaproblemen.

Första versionen är inte meningslös, den finns för att ge dig insikter och verklig användardata.

Tänk på det så här:

• Version 1: Du löser problemet som du tror att det är
• Version 2: Du löser problemet som det faktiskt är
• Version 3: Du löser det snyggt

Därför gäller det att nå version 3 så snabbt som möjligt, utan att fastna på detaljer i början. Lägg inte för mycket tid på att finslipa det första försöket. Det viktiga är att ta sig vidare och lära av verkliga användare.

Att lansera tidigt ger dig superkrafter

När du släpper något tidigt möter du verkligheten direkt. Istället för att gissa vad som är rätt får du äkta återkoppling från användare.

Den återkopplingen är guld värd. Den visar dig:

• Vilka funktioner som faktiskt används (och vilka som ignoreras)
• Var prestandaproblemen verkligen är (inte där du trodde)
• Vilka specialfall som faktiskt förekommer (inte de 50 du föreställde dig)
• Hur användare faktiskt arbetar (vilket sällan matchar dina antaganden)

Med den kunskapen kan du fatta smarta beslut. Du kan refaktorera det som behövs, inte allt. Du kan optimera det som är långsamt, inte det som kanske skulle kunna bli långsamt. Du kan bygga funktioner som användare vill ha, inte funktioner som du tror att de vill ha.

Det är en stor skillnad mellan att gissa och att veta.

Omfamna iterationen

Snabb iteration ger dig en enorm fördel: du lär dig vad som faktiskt spelar roll.

När du lanserar tidigt och ofta får du information som är omöjlig att ha i förväg. Du ser vilka funktioner som används varje dag och vilka som ignoreras helt. Du märker var systemet faktiskt är långsamt under verklig belastning. Du förstår vilka specialfall som händer i produktion.

Skillnaden är att du inte längre gissar – du vet.

Varje iteration ger dig bättre förutsättningar än föregående. Första versionen löste problemet du trodde fanns. Andra versionen löser problemet som det faktiskt är. Tredje versionen löser det snyggt och effektivt.

Det här är inte slöseri med tid. Det är hur du bygger rätt sak.

Så nästa gång du sitter och polerar kod som ingen använt än, fråga dig:

• Kan jag lansera en enklare version av detta idag?
• Vilken information saknar jag som endast verkliga användare kan ge mig?
• Vad är det minsta jag behöver bygga för att få den informationen?

Lansera sedan det minsta. Få återkoppling. Lägg nästa iteration på det du lär dig.

Kod är inte en produktionslinje där du bygger något en gång och är klar. Det är en process där varje iteration gör dig lite klokare på vad som faktiskt behövs.

Slutsats: Våga lansera innan det är perfekt

Mjukvara blir aldrig rätt första gången. Inte för att du är dålig på att koda, utan för att du inte kan veta vad "rätt" är förrän du sett hur det används i verkligheten.

Varje timme du lägger på att polera kod som ingen använt är en timme du kunde ha använt till att lära dig vad som faktiskt behövs. Att lansera tidigt är inte att vara lat – det är att vara smart. Det är så du bygger rätt sak istället för att bygga saker rätt.

Så sluta vänta på perfektion. Bygg något som fungerar tillräckligt bra. Lansera det idag. Se vad som händer. Lär dig från riktiga användare. Bygg vidare på det.

Den koden du är orolig för att lansera? Den kommer du skriva om ändå när du väl förstår problemet ordentligt. Så varför inte göra det nu och börja lära dig redan idag?

Lansera snabbt. Lär dig snabbt. Förbättra snabbt.