5 djärva drag inom mjukvaruutveckling som alla kallade vansinniga – tills de fungerade
Programvaruutveckling är full av välkända ramverk—Agilt, Vattenfallsmodellen, Scrum—alla stabila val som hjälper team att leverera i tid och med färre överraskningar.
Men ibland blir vi så bekväma med att följa dessa väl upptrampade stigar att vi glömmer att verkliga genombrott ofta sker när någon provar något som ser vansinnigt ut på papperet. Det är riskabelt, visst, men det är vanligtvis där de stora vinsterna finns.
“AI är verkligen bra på att göra 70 % av arbetet snabbare”, säger Alex Zajac, SDE & AI på Amazon och skapare av nyhetsbrevet Hungry Minds. “Men de sista 30 % är de svåraste—att sätta det i produktion, se till att det inte hallucinerar och konfigurera skyddsräcken för utvärdering.”
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Med andra ord handlar djärv programvaruutveckling inte bara om att använda nya verktyg—det handlar om att göra det hårda och oglamorösa arbetet med att få dem att faktiskt fungera.
De flesta företag håller sig till den vanliga spelplanen eftersom den uppfattas som “säker”. Ingen får skulden för att ha gått sin egen väg om en idé inte fungerar inom en standardiserad process. Enligt en McKinsey-undersökning från 2023 är företag som uppmuntrar kalkylerat risktagande dock 1,7x mer benägna att överträffa branschkollegor när det gäller innovationsmått.
Och även när vi vet att djärvt tänkande kan löna sig är det förvånansvärt ovanligt att hitta miljöer som verkligen belönar experimenterande. Alltför få organisationer uppmuntrar uttryckligen risktagande i programvaruprojekt.
Tidiga användare, eller ibland rena pionjärer, får ofta definiera reglerna innan alla andra ens vet att de finns.
Trots all rädsla och tvekan finns det team där ute som tog ett stort språng och landade i något briljant. Här är fem strategier som först verkade okonventionella—eller kanske alltför kaotiska—för att lyckas.
Strategi #1: Kaosteknik (Netflix)
Netflix ”Chaos Monkey” bryter avsiktligt sönder system i produktion för att testa motståndskraften. Låter vansinnigt, eller hur? Men detta tillvägagångssätt hjälpte Netflix att upprätthålla 99.99% upptid samtidigt som tjänsten växte från 7 miljoner till över 230 miljoner abonnenter.
”Vi insåg att det inte var en strategi att hoppas på stabilitet”, sade den tidigare Netflix-ingenjören Kolton Andrus. ”Genom att regelbundet framkalla fel slutade våra team att frukta avbrott och byggde som standard mer robusta system.”
Den centrala insikten var kontraintuitiv: att skapa kontrollerade fel förhindrade faktiskt katastrofala fel. Netflix tester med felinjektering avslöjade svagheter som annars hade förblivit dolda tills ett större avbrott inträffade.
Praktiskt tips: Börja med en ”speldag” där ni simulerar fel i en miljö som inte är produktion. Välj en kritisk tjänst och introducera enkla fel, som att stänga av instanser eller kapa nätverksanslutningar. Dokumentera vad som går sönder och åtgärda dessa sårbarheter innan de orsakar verkliga problem.
Strategi #2: Kontinuerlig driftsättning (Flickr)
År 2009, när de flesta företag driftsatte månadsvis, fick Flickrs presentation ”10 driftsättningar om dagen” folk att häpna. Team oroade sig för att mindre och frekventa lanseringar skulle skapa kaos, men Flickr fann motsatsen: mer frekventa lanseringar minskade faktiskt risken dramatiskt.
Matematiken är enkel men kraftfull: om du driftsätter 5–10 ändringar åt gången är det enkelt att isolera problem. Om du driftsätter 500 ändringar efter en månad, lycka till med att hitta nålen i höstacken.
Mindre driftsättningspaket = mindre konsekvensområde.
Företag som inför CD rapporterar 70 % färre produktionsfel och 24 gånger snabbare återhämtning när problem väl uppstår, enligt rapporten State of DevOps 2023. Metoden har sedan dess blivit standard på teknikföretag av alla storlekar.
Praktiskt tips: Inför ett tillvägagångssätt med ”driftsättningsfönster” där team gradvis ökar driftsättningsfrekvensen. Börja med att gå från månatliga till veckovisa driftsättningar, sedan två gånger i veckan, tills ni har byggt upp den automatisering och det självförtroende som krävs för att driftsätta flera gånger om dagen. Fokusera på att bygga en robust testsvit som körs automatiskt före varje driftsättning.
Strategi #3: Helt distansbaserad modell (GitLab)
Före pandemin verkade GitLabs helt distansbaserade struktur radikal. Ändå gjorde den det möjligt för dem att anställa de bästa talangerna globalt och tvingade fram utmärkta dokumentationsrutiner från dag ett.
GitLabs offentliga handbok (nu över 15 000 sidor) blev deras hemliga vapen och eliminerade problemet ”Det visste jag inte” som plågar många distribuerade team. Detta dokumentationsorienterade arbetssätt innebar att nyanställda kunde komma igång snabbare och gjorde beslutsfattandet mer transparent.
Dokumentation skalar bättre än tyst kunskap. Tänk stort!
”När du inte kan knacka någon på axeln för att få information tvingas du dokumentera allt tydligt”, förklarar Darren Murph, GitLabs chef för distansarbete. ”Detta skapar en organisatorisk motståndskraft som kontorscentrerade företag sällan uppnår.”
Praktiskt råd: Även om ni inte arbetar helt på distans bör ni införa en dokumentationspraxis med distansarbete i första hand. Skapa en centraliserad kunskapsbas för alla viktiga beslut, processer och all tyst kunskap. Inför en regel om att något inte existerar om det inte är dokumenterat. Gå igenom dokumentationen kvartalsvis för att hålla den aktuell.
Strategi nr 4: Trunkbaserad utveckling (Etsy)
Etsy övergav komplexa förgreningsstrategier till förmån för en modell där alla ofta skickar in ändringar till den huvudsakliga kodbasen. Detta arbetssätt utmanade den konventionella uppfattningen att utvecklare behöver isolerade funktionsgrenar för att kunna arbeta effektivt.
”Vi upptäckte att långlivade grenar skapade en falsk känsla av trygghet”, säger den tidigare Etsy-ingenjören Daniel Schauenberg. ”I själva verket fördröjde de bara problemen med integreringen och skapade större konflikter när grenarna till slut slogs samman.”
Trunkbaserad utveckling hjälpte Etsy att växa från 50 till över 2 000 utvecklare och samtidigt distribuera kod över 50 gånger om dagen. Arbetssättet tvingade teamet att bygga bättre automatiserade tester eftersom huvudgrenen behövde hållas ren, och det eliminerade det alltför vanliga ”sammanfogningshelvetet” som team möter med funktionsgrenar.
Alex noterade ett liknande mönster när han pratade om AI och kodbaser med mycket kontext. ”Saker som är väldigt tätt kopplade till era egna system … kommer att kräva många människor”, sade han.
I snabbföränderliga miljöer måste team som arbetar direkt i huvudgrenen ha en djup förståelse för systemdesign och avvägningar – eftersom det finns mindre utrymme att gömma sig bakom långlivade grenar. Det handlar inte bara om att skicka in kod snabbare, utan om att ingenjörerna kommer närmare den verkliga komplexiteten.
Praktiskt råd: Implementera funktionsflaggor för att dölja pågående arbete samtidigt som ni skickar in ändringar till huvudgrenen varje dag. Börja med ett litet, betrott team för att bygga förtroende för arbetssättet. Sätt upp ett teammål att skicka in ändringar till huvudgrenen minst en gång om dagen och mät hur integrationsproblemen minskar över tid.
Er strategi för funktionsflaggor är verkligen viktig för vad ni visar era kunder!
Strategi nr 5: Öppen källkod som standard (Hashicorp)
Hashicorp byggde ett miljardföretag genom att göra sina centrala infrastrukturverktyg, som Terraform, Vault och Consul, till öppen källkod. I motsats till traditionella affärsmodeller för programvara möjliggjorde denna strategi snabb spridning och bidrag från tusentals utvecklare världen över.
”När vi började trodde folk att vi var galna som gav bort vår bästa kod”, säger medgrundaren Mitchell Hashimoto. ”Men vi upptäckte att en bred användning skapar mer värde än det man förlorar i möjliga licensintäkter.”
För enskilda utvecklare kan valet av rätt AI-förstärkta verktyg följa en liknande logik. Alex berättade att han nyligen valde att köpa Cursor Pro eftersom ”det helt enkelt förstår mig eller förstår den stil jag arbetar med.” Precis som HashiCorp satsade på förtroende och gemenskapens behov med öppen källkod dras ingenjörer nu till verktyg som intuitivt förstår deras arbetsflöden – även när det innebär att välja det mindre vanliga alternativet.
Deras Terraform-verktyg fick över 100 000 stjärnor på GitHub och blev en branschstandard – något som skulle ha tagit årtionden med ett traditionellt tillvägagångssätt med sluten källkod. Företaget tjänar pengar på företagsfunktioner, support och värdtjänster, samtidigt som det behåller goodwill från en stor utvecklargemenskap.
Åtgärd att vidta: Identifiera komponenter i din programvara som skulle kunna dra nytta av engagemang från communityn. Börja med att publicera ett användbart bibliotek eller verktyg som inte är en del av din kärn-IP som öppen källkod. Skapa en process för bidrag som gör det enkelt för utomstående att förbättra din kod, och investera i bra dokumentation för att underlätta användningen.
Den gemensamma nämnaren
Det som förenar dessa strategier är inte bara djärvhet – det är kalkylerat risktagande med täta återkopplingsloopar. Varje team byggde mekanismer för att snabbt lära sig av misstag och korrigera kursen.
Alex nämnde hur AI förändrar vad det innebär att vara utvecklare. “Vi blir inte ersatta,” säger han, “men ansvarsområdet håller på att förändras.”
Vissa säger att utvecklare blir mer som produkttekniker, medan andra förutspår en uppdelning mellan generalister och specialister. Oavsett vilket lyckas djärva utvecklingsstrategier i dag inte bara tack vare innovativa verktyg – de lyckas när team är villiga att anpassa sina arbetsflöden, roller och tankesätt.
När du omprövar dina utvecklingsstrategier kan valet av rätt partner göra hela skillnaden. Du kan till exempel överväga att samarbeta med antingen ett företag för anpassad programvaruutveckling eller ett företag för programvaruutveckling på nära håll, till exempel.
Prenumerera på nyhetsbrevet från The CTO Club för fler tips, verktyg och bästa praxis inom programvaruutveckling.
