5 modige softwareudviklingstræk, som alle kaldte vanvittige – indtil de virkede

Softwareudvikling er fyldt med velkendte rammeværker—agil udvikling, vandfaldsmodellen, Scrum—alle solide valg, der hjælper teams med at levere til tiden og med færre overraskelser.

Men nogle gange bliver vi så vant til at følge disse velkendte stier, at vi glemmer, at reelle gennembrud ofte opstår, når nogen prøver noget, der ser vanvittigt ud på papiret. Det er risikabelt, ja, men det er som regel dér, de store gevinster gemmer sig.

“AI er virkelig god til at udføre 70 % af arbejdet hurtigere,” siger Alex Zajac, SDE & AI hos Amazon og skaberen af Hungry Minds-nyhedsbrevet. “Men de sidste 30 % er de sværeste—at få det i produktion, sikre at det ikke hallucinerer og etablere evalueringsværn.”

Med andre ord handler modig softwareudvikling ikke kun om at bruge nye værktøjer—det handler om at udføre det hårde, uglamourøse arbejde med at få dem til faktisk at fungere.

De fleste virksomheder holder sig til den sædvanlige drejebog, fordi den opfattes som “sikker”. Ingen bliver holdt ansvarlig for at gå egne veje, hvis en idé ikke lykkes under en standardiseret proces. Ifølge en McKinsey-undersøgelse fra 2023 er virksomheder, der tilskynder til kalkuleret risikotagning, dog 1,7x mere tilbøjelige til at overgå branchekolleger på innovationsmålinger.

Og selv når vi ved, at modig tænkning kan betale sig, er det overraskende sjældent at finde miljøer, der reelt belønner eksperimentering. Alt for få organisationer tilskynder eksplicit til risikotagning i softwareprojekter.

Tidlige brugere eller ligefrem pionerer får ofte mulighed for at definere reglerne, før alle andre overhovedet ved, at de findes.

Trods al frygten og tøven findes der teams, som tog et vovet spring og landede på noget genialt. Her er fem strategier, der oprindeligt virkede utraditionelle—eller måske for kaotiske—til at kunne lykkes.

Strategi nr. 1: Kaosteknik (Netflix)

Netflix' "Chaos Monkey" ødelægger med vilje systemer i produktion for at teste modstandsdygtigheden. Det lyder vanvittigt, ikke? Men denne tilgang hjalp Netflix med at opretholde 99,99 % oppetid, mens tjenesten voksede fra 7 millioner til over 230 millioner abonnenter.

"Vi indså, at det ikke var en strategi at håbe på stabilitet," sagde den tidligere Netflix-ingeniør Kolton Andrus. "Ved regelmæssigt at fremkalde fejl holdt vores teams op med at frygte driftsafbrydelser og byggede som standard mere robuste systemer."

Den afgørende indsigt var kontraintuitiv: Kontrollerede fejl forhindrede faktisk katastrofale fejl. Netflix' test med fejlinjektion afslørede svagheder, som ellers ville være forblevet skjulte, indtil en større driftsafbrydelse opstod.

Praktisk råd: Begynd med en "spildag", hvor I simulerer fejl i et miljø, der ikke er produktion. Vælg én kritisk tjeneste, og introducer simple fejl som at lukke instanser ned eller afbryde netværksforbindelser. Dokumentér, hvad der går i stykker, og udbedr disse sårbarheder, før de forårsager reelle problemer.

Strategi nr. 2: Kontinuerlig implementering (Flickr)

I 2009, da de fleste virksomheder implementerede månedligt, vakte Flickrs præsentation "10 implementeringer om dagen" stor opsigt. Teams frygtede, at mindre og hyppigere udgivelser ville skabe kaos, men Flickr fandt det modsatte: Hyppigere udgivelser reducerede faktisk risikoen markant.

Regnestykket er enkelt, men effektivt: Hvis du implementerer 5-10 ændringer ad gangen, er det ligetil at isolere problemer. Hvis du implementerer 500 ændringer efter en måned, så held og lykke med at finde nålen i høstakken.

Virksomheder, der indfører CD, rapporterer 70 % færre produktionsfejl og 24x hurtigere genoprettelse, når der faktisk opstår problemer, ifølge rapporten om DevOps' tilstand fra 2023. Metoden er siden blevet standard i teknologivirksomheder af alle størrelser.

Praktisk råd: Indfør en tilgang med et "implementeringsvindue", hvor teams gradvist øger implementeringsfrekvensen. Begynd med at gå fra månedlige til ugentlige implementeringer, derefter to gange om ugen, indtil I har opbygget den automatisering og tillid, der skal til for at implementere flere gange dagligt. Fokuser på at opbygge en robust testpakke, der kører automatisk før hver implementering.

Strategi nr. 3: Model med fuldt fjernarbejde (GitLab)

Før pandemien virkede GitLabs fuldt fjernbaserede struktur radikal. Ikke desto mindre gjorde den det muligt for virksomheden at ansætte de bedste talenter globalt og tvang den til at etablere fremragende dokumentationspraksisser fra dag ét.

GitLabs offentlige håndbog (nu på over 15.000 sider) blev deres hemmelige våben og eliminerede problemet med "Det vidste jeg ikke", som plager mange distribuerede teams. Denne dokumentationsfokuserede tilgang betød, at nye medarbejdere hurtigere kunne komme ombord, og at beslutningstagningen blev mere transparent.

"Når du ikke kan prikke nogen på skulderen for at få oplysninger, bliver du tvunget til at dokumentere alting tydeligt," forklarer Darren Murph, GitLabs chef for fjernarbejde. "Det skaber en organisatorisk robusthed, som kontorcentrerede virksomheder sjældent opnår."

Praktisk konklusion: Selvom I ikke arbejder fuldt ud distribueret, bør I indføre en praksis, hvor dokumentation kommer først i fjernarbejde. Opret en centraliseret vidensbase for alle vigtige beslutninger, processer og tavs viden. Indfør en regel om, at hvis noget ikke er dokumenteret, eksisterer det ikke. Gennemgå denne dokumentation hvert kvartal for at holde den opdateret.

Strategi nr. 4: Udvikling baseret på hovedgrenen (Etsy)

Etsy droppede komplekse forgreningsstrategier til fordel for en model, hvor alle ofte indsender ændringer til den primære kodebase. Denne tilgang udfordrede den konventionelle opfattelse af, at udviklere har brug for isolerede funktionsgrene for at kunne arbejde effektivt.

"Vi fandt ud af, at langvarige grene skabte en falsk følelse af sikkerhed," siger den tidligere Etsy-ingeniør Daniel Schauenberg. "I virkeligheden udskød de blot integrationsproblemerne og skabte større konflikter, når grenene endelig blev flettet sammen."

Udvikling baseret på hovedgrenen hjalp Etsy med at skalere fra 50 til over 2.000 udviklere, samtidig med at de stadig udrullede over 50 gange dagligt. Tilgangen tvang teamet til at opbygge bedre automatiserede tests, eftersom den primære gren skulle forblive ren, og den eliminerede det alt for almindelige "sammenfletningshelvede", som teams oplever med funktionsgrene.

Alex bemærkede et lignende mønster, da han talte om AI og konteksttunge kodebaser. “Ting, der er virkelig tæt koblet til jeres proprietære systemer … vil kræve mange mennesker,” sagde han.

I miljøer, der bevæger sig hurtigt, er teams, der arbejder direkte i hovedgrenen, nødt til at forstå systemdesign og afvejninger i dybden—fordi der er mindre plads til at gemme sig bag langvarige grene. Det handler ikke kun om at indsende kodeændringer hurtigere; det handler om, at ingeniørerne kommer tættere på den reelle kompleksitet.

Praktisk konklusion: Implementer funktionsflag for at skjule arbejde, der stadig er under udvikling, mens I indsender ændringer til den primære gren dagligt. Begynd med et lille, betroet team for at opbygge tillid til tilgangen. Sæt et teammål om at indsende ændringer til den primære gren mindst én gang dagligt, og mål reduktionen i integrationsproblemer over tid.

Strategi nr. 5: Åben kildekode som standard (Hashicorp)

Hashicorp opbyggede en virksomhed til en milliard dollar ved at gøre deres centrale infrastrukturværktøjer som Terraform, Vault og Consul til åben kildekode. I modsætning til traditionelle softwareforretningsmodeller muliggjorde denne strategi hurtig udbredelse og bidrag fra tusindvis af udviklere verden over.

"Da vi startede, syntes folk, at vi var vanvittige, fordi vi gav vores bedste kode væk," bemærker medstifter Mitchell Hashimoto. "Men vi fandt ud af, at bred udbredelse skaber mere værdi, end man mister i potentielle licensindtægter."

For individuelle udviklere kan valget af de rigtige AI-forstærkede værktøjer følge en lignende logik. Alex fortalte, at han for nylig valgte at købe Cursor Pro, fordi “det bare forstår mig eller forstår den stil, jeg arbejder med.” Ligesom HashiCorp satsede på tillid og et godt match med fællesskabet gennem åben kildekode, søger ingeniører nu mod værktøjer, der intuitivt forstår deres arbejdsgange—selv når det betyder, at de vælger den mindre udbredte løsning.

Deres Terraform-værktøj opnåede over 100.000 GitHub-stjerner og blev en standard i branchen—noget, der ville have taget årtier med en traditionel tilgang med lukket kildekode. Virksomheden tjener penge på virksomhedsfunktioner, support og driftede tjenester, samtidig med at den bevarer velviljen fra et stort udviklerfællesskab.

Handlingsorienteret konklusion: Identificer komponenter i din software, som kunne drage fordel af fællesskabets involvering. Start med at gøre et nyttigt bibliotek eller værktøj, som ikke er en del af din kerne-IP, til åben kildekode. Opbyg en bidragsproces, der gør det nemt for udefrakommende at forbedre din kode, og invester i god dokumentation for at lette udbredelsen.

Den fælles tråd

Det, der forbinder disse strategier, er ikke blot mod—det er kalkuleret risiko med tætte feedbacksløjfer. Hvert team opbyggede mekanismer til hurtigt at lære af fejl og korrigere kursen.

Alex nævnte, hvordan AI ændrer, hvad det betyder at være udvikler. “Vi bliver ikke erstattet,” siger han, “men det glidende ansvarsvindue flytter sig.”

Nogle siger, at udviklere bliver mere som produktingeniører; andre forudser en opdeling mellem generalister og specialister. Uanset hvad lykkes modige udviklingsstrategier i dag ikke kun på grund af innovative værktøjer—de lykkes, når teams er villige til at tilpasse deres arbejdsgange, roller og tankegang.

Når du gentænker dine udviklingsstrategier, kan det gøre hele forskellen at finde de rette partnere. Du kan for eksempel overveje at samarbejde med enten en virksomhed inden for skræddersyet softwareudvikling eller en softwareudviklingsvirksomhed med udvikling i nærliggende lande, for eksempel.

Tilmeld dig The CTO Clubs nyhedsbrev for at få flere tips, værktøjer og bedste praksisser inden for softwareudvikling.