Programvareutvikling er full av velkjente rammeverk—Agile, Waterfall, Scrum—alle solide valg som hjelper team med å levere i tide og med færre overraskelser.
Men noen ganger blir vi så komfortable med å følge disse veltråkkede stiene at vi glemmer at virkelige gjennombrudd ofte kommer når noen prøver noe som ser helt sprøtt ut på papiret. Det er risikabelt, absolutt, men det er vanligvis der de store gevinstene skjuler seg.
«AI er virkelig god til å gjøre 70 % av arbeidet raskere», sier Alex Zajac, SDE & AI hos Amazon og skaperen av Hungry Minds-nyhetsbrevet. «Men de siste 30 % er de vanskeligste—å sette det i produksjon, sørge for at det ikke hallusinerer og etablere evalueringsrammer.»
Med andre ord handler dristig programvareutvikling ikke bare om å bruke nye verktøy—det handler om å gjøre det harde og lite glamorøse arbeidet med å få dem til å faktisk fungere.
De fleste selskaper holder seg til den vanlige oppskriften fordi den oppfattes som «trygg». Ingen får skylden for å gå sine egne veier hvis en idé ikke lykkes innenfor en standardprosess. Ifølge en McKinsey-undersøkelse fra 2023 har imidlertid selskaper som oppmuntrer til kalkulert risikotaking, 1,7 ganger større sannsynlighet for å prestere bedre enn bransjekolleger på innovasjonsmål.
Og selv når vi vet at dristig tenkning kan lønne seg, er det overraskende sjelden å finne miljøer som virkelig belønner eksperimentering. Altfor få organisasjoner oppmuntrer eksplisitt til risikotaking i programvareprosjekter.
Tidlige brukere, eller noen ganger rene pionerer, får ofte definere reglene før alle andre i det hele tatt vet at de finnes.
Til tross for all frykten og nølingen finnes det team der ute som tok et stort sprang og landet på noe briljant. Her er fem strategier som først virket uortodokse—eller kanskje for kaotiske—til å lykkes.
Strategi nr. 1: Kaosteknikk (Netflix)
Netflix' «Chaos Monkey» bryter med vilje systemer i produksjon for å teste motstandsdyktighet. Høres vanvittig ut, ikke sant? Men denne tilnærmingen hjalp Netflix med å opprettholde 99,99 % oppetid samtidig som selskapet vokste fra 7 millioner til over 230 millioner abonnenter.
«Vi innså at det å håpe på stabilitet ikke var en strategi», sa den tidligere Netflix-ingeniøren Kolton Andrus. «Ved å tilføre feil regelmessig sluttet teamene våre å frykte driftsavbrudd og bygde mer robuste systemer som standard.»
Den viktigste innsikten var kontraintuitiv: Å skape kontrollerte feil forhindret faktisk katastrofale feil. Netflix' testing med feilinjektering avdekket svakheter som ellers ville ha forblitt skjulte frem til et større driftsavbrudd oppsto.
Praktisk råd: Start med en «spilldag» der dere simulerer feil i et miljø som ikke er i produksjon. Velg én kritisk tjeneste og introduser enkle feil, som å avslutte instanser eller kutte nettverksforbindelser. Dokumenter hva som går galt, og utbedre disse sårbarhetene før de skaper reelle problemer.
Have an account? Log In
Strategi nr. 2: Kontinuerlig utrulling (Flickr)
I 2009, da de fleste selskaper rullet ut oppdateringer månedlig, vakte Flickrs presentasjon «10 utrullinger om dagen» stor oppsikt. Teamene var bekymret for at mindre og hyppigere lanseringer skulle skape kaos, men Flickr fant det motsatte: Hyppigere lanseringer reduserte faktisk risikoen betydelig.
Matematikken er enkel, men kraftfull: Hvis du ruller ut 5–10 endringer om gangen, er det enkelt å isolere problemer. Hvis du ruller ut 500 endringer etter en måned, ønsker jeg deg lykke til med å finne nålen i høystakken.
Mindre utrullingspuljer = mindre konsekvensområde.
Selskaper som tar i bruk CD, rapporterer om 70 % færre produksjonsfeil og 24 ganger raskere gjenoppretting når problemer faktisk oppstår, ifølge rapporten om DevOps-tilstanden fra 2023. Praksisen har siden blitt standard i teknologiselskaper av alle størrelser.
Praktisk råd: Innfør en tilnærming med «utrullingsvindu» der teamene gradvis øker utrullingsfrekvensen. Begynn med å gå fra månedlige til ukentlige utrullinger, deretter to ganger i uken, frem til dere har bygget opp automatiseringen og tryggheten som trengs for å rulle ut flere ganger daglig. Fokuser på å bygge en robust testpakke som kjøres automatisk før hver utrulling.
Strategi nr. 3: Heldistribuert modell (GitLab)
Før pandemien virket GitLabs fullt distribuerte struktur radikal. Likevel gjorde den det mulig for selskapet å ansette de beste talentene globalt og tvang frem gode dokumentasjonsrutiner fra dag én.
GitLabs offentlige håndbok (nå på over 15 000 sider) ble deres hemmelige våpen og eliminerte problemet «Det visste jeg ikke» som plager mange distribuerte team. Denne dokumentasjonsorienterte tilnærmingen gjorde at nyansatte kunne komme raskere i gang, og gjorde beslutningstaking mer transparent.
Dokumentasjon skalerer bedre enn taus kunnskap. Tenk stort!
«Når du ikke kan lene deg over til noen for å få informasjon, blir du tvunget til å dokumentere alt tydelig», forklarer Darren Murph, GitLabs leder for fjernarbeid. «Dette skaper organisatorisk motstandsdyktighet som kontorsentrerte selskaper sjelden oppnår.»
Konkrete tiltak: Selv om dere ikke jobber fullstendig distribuert, bør dere ta i bruk en dokumentasjonspraksis som setter fjernarbeid først. Opprett en sentralisert kunnskapsbase for alle viktige beslutninger, prosesser og tause kunnskaper. Innfør en regel om at noe ikke eksisterer dersom det ikke er dokumentert. Gå gjennom dokumentasjonen hvert kvartal for å holde den oppdatert.
Strategi nr. 4: Trunk-basert utvikling (Etsy)
Etsy droppet komplekse forgreningsstrategier til fordel for en modell der alle bidrar til hovedkodebasen ofte. Denne tilnærmingen utfordret den konvensjonelle oppfatningen om at utviklere trenger isolerte funksjonsgrener for å jobbe effektivt.
«Vi oppdaget at langvarige grener skapte en falsk trygghetsfølelse», sier den tidligere Etsy-utvikleren Daniel Schauenberg. «I virkeligheten utsatte de bare integrasjonssmerten og skapte større konflikter da grenene til slutt ble slått sammen.»
Trunk-basert utvikling hjalp Etsy med å skalere fra 50 til over 2 000 utviklere, samtidig som de fortsatt distribuerte over 50 ganger daglig. Tilnærmingen tvang teamet til å bygge bedre automatiserte tester, siden hovedgrenen måtte holdes ren, og eliminerte det altfor vanlige «flettehelvetet» som team møter med funksjonsgrener.
Alex påpekte et lignende mønster da han snakket om kunstig intelligens og kodebaser med mye kontekst. «Ting som er virkelig tett koblet til de proprietære systemene deres … vil kreve mange mennesker», sa han.
I miljøer i rask endring må team som jobber direkte i trunk, ha en dyp forståelse av systemdesign og avveininger – fordi det er mindre rom for å skjule seg bak langvarige grener. Det handler ikke bare om å legge inn kode raskere, men om at ingeniørene kommer tettere på den reelle kompleksiteten.
Konkrete tiltak: Implementer funksjonsbrytere for å skjule arbeid som pågår, samtidig som dere legger inn endringer i hovedgrenen daglig. Start med et lite, tillitsbasert team for å bygge trygghet rundt tilnærmingen. Sett et teammål om å legge inn endringer i hovedgrenen minst én gang daglig, og mål reduksjonen i integrasjonsproblemer over tid.
Strategien deres for funksjonsbrytere er svært viktig for hva dere viser kundene deres!
More Articles
Strategi nr. 5: Åpen kildekode som standard (Hashicorp)
Hashicorp bygget en virksomhet verdt én milliard dollar ved å gjøre de sentrale infrastrukturløsningene sine, som Terraform, Vault og Consul, til åpen kildekode. I motsetning til tradisjonelle programvaremodeller muliggjorde denne strategien rask utbredelse og bidrag fra tusenvis av utviklere over hele verden.
«Da vi startet, trodde folk at vi var gale som ga bort den beste koden vår», forteller medgrunnlegger Mitchell Hashimoto. «Men vi oppdaget at bred utbredelse skaper mer verdi enn det man taper i potensielle lisensinntekter.»
For individuelle utviklere kan det å velge riktige verktøy med støtte for kunstig intelligens følge en lignende logikk. Alex fortalte at han nylig valgte å kjøpe Cursor Pro fordi «det bare forstår meg eller forstår stilen jeg jobber med». På samme måte som HashiCorp satset på tillit og samsvar med fellesskapet gjennom åpen kildekode, trekkes ingeniører nå mot verktøy som intuitivt forstår arbeidsflytene deres – selv når det innebærer å velge det mindre utbredte alternativet.
Terraform-verktøyet deres fikk over 100 000 stjerner på GitHub og ble en bransjestandard – noe som ville ha tatt flere tiår med en tradisjonell tilnærming basert på lukket kildekode. Selskapet tjener penger på bedriftsfunksjoner, brukerstøtte og driftede tjenester, samtidig som de opprettholder goodwill fra et massivt utviklerfellesskap.
Praktisk råd: Identifiser komponenter i programvaren din som kan ha nytte av involvering fra fellesskapet. Begynn med å gjøre et nyttig bibliotek eller verktøy som ikke er en del av kjerne-IP-en din, tilgjengelig som åpen kildekode. Utarbeid en prosess for bidrag som gjør det enkelt for utenforstående å forbedre koden din, og invester i god dokumentasjon for å legge til rette for bruk.
Den røde tråden
Det som knytter disse strategiene sammen, er ikke bare dristighet – det er kalkulert risiko med korte tilbakemeldingssløyfer. Hvert team bygget mekanismer for å lære raskt av feil og korrigere kursen.
Alex nevnte hvordan KI endrer hva det betyr å være utvikler. «Vi blir ikke erstattet,» sier han, «men det glidende ansvarsintervallet er i endring.»
Noen mener utviklere blir mer som produktutviklere, mens andre spår en todeling mellom generalister og spesialister. Uansett lykkes ikke dristige utviklingsstrategier i dag bare på grunn av innovative verktøy – de lykkes når team er villige til å tilpasse arbeidsflytene, rollene og tankegangen sin.
Når du tenker gjennom utviklingsstrategiene dine på nytt, kan det å finne de rette partnerne utgjøre hele forskjellen. Du kan for eksempel vurdere å samarbeide med enten et selskap for utvikling av skreddersydd programvare eller et nærkystbasert programvareutviklingsselskap, for eksempel.
Abonner på nyhetsbrevet til The CTO Club for flere tips, verktøy og beste praksis innen programvareutvikling.
