Softwareontwikkeling staat bol van vertrouwde raamwerken—Agile, Waterval, Scrum—allemaal solide keuzes die teams helpen om op tijd en met minder verrassingen te leveren.
Maar soms raken we zo gewend aan het volgen van deze platgetreden paden dat we vergeten dat echte doorbraken vaak ontstaan wanneer iemand iets probeert dat er op papier volkomen absurd uitziet. Het is riskant, zeker, maar daar zijn de grote successen meestal te vinden.
“AI is er echt goed in om 70% van het werk sneller te doen,” zegt Alex Zajac, SDE & AI bij Amazon en maker van de Hungry Minds-nieuwsbrief. “Maar die laatste 30% is het moeilijkst—het in productie brengen, ervoor zorgen dat het niet hallucineert en evaluatievangrails instellen."
Met andere woorden: gedurfde softwareontwikkeling draait niet alleen om het gebruiken van nieuwe tools—het gaat erom het moeilijke, weinig glamoureuze werk te doen om ze daadwerkelijk te laten werken.
De meeste bedrijven houden zich aan het gebruikelijke draaiboek omdat het als “veilig” wordt gezien. Niemand krijgt de schuld als een idee niet uitpakt wanneer je een standaardproces volgt. Volgens een onderzoek van McKinsey uit 2023 hebben bedrijven die weloverwogen risiconeming aanmoedigen echter 1,7x meer kans om beter te presteren dan sectorgenoten op innovatie-indicatoren.
En zelfs als we weten dat gedurfd denken kan lonen, zijn omgevingen die experimenten echt belonen verrassend zeldzaam. Te weinig organisaties moedigen het nemen van risico's bij softwareprojecten expliciet aan.
Vroege gebruikers, of soms regelrechte pioniers, krijgen vaak de kans om de regels te bepalen voordat alle anderen überhaupt weten dat ze bestaan.
Ondanks alle angst en aarzeling zijn er teams die een enorme sprong in het diepe waagden en op iets briljants uitkwamen. Hier zijn vijf strategieën die aanvankelijk ongebruikelijk—of misschien te chaotisch—leken om succesvol te zijn.
Strategie #1: Chaosengineering (Netflix)
Netflix' "Chaos Monkey" zorgt er opzettelijk voor dat systemen in productie uitvallen om de veerkracht te testen. Klinkt krankzinnig, toch? Maar deze aanpak hielp Netflix om een beschikbaarheid van 99,99% te behouden tijdens de groei van 7 miljoen naar meer dan 230 miljoen abonnees.
"We beseften dat hopen op stabiliteit geen strategie was," zei voormalig Netflix-engineer Kolton Andrus. "Door regelmatig storingen te veroorzaken, waren onze teams niet langer bang voor uitval en bouwden ze standaard robuustere systemen."
Het belangrijkste inzicht was contra-intuïtief: door gecontroleerde storingen te creëren, werden catastrofale storingen juist voorkomen. Netflix' tests waarbij storingen werden geïnjecteerd, brachten zwakke plekken aan het licht die verborgen zouden zijn gebleven totdat er een grote uitval plaatsvond.
Praktische tip: Begin met een "simulatiedag" waarop je storingen simuleert in een niet-productieomgeving. Kies één kritieke service en introduceer eenvoudige storingen, zoals het uitschakelen van instanties of het verbreken van netwerkverbindingen. Documenteer wat er kapotgaat en verhelp die kwetsbaarheden voordat ze echte problemen veroorzaken.
Have an account? Log In
Strategie #2: Continue implementatie (Flickr)
In 2009, toen de meeste bedrijven maandelijks implementeerden, sloeg de presentatie van Flickr met de titel "10 implementaties per dag" in als een bom. Teams waren bang dat kleinere, frequente releases chaos zouden veroorzaken, maar Flickr ontdekte het tegenovergestelde: frequentere releases verminderden het risico juist aanzienlijk.
De berekening is eenvoudig maar krachtig: als je 5-10 wijzigingen tegelijk implementeert, isoleer je problemen eenvoudig. Als je na een maand 500 wijzigingen implementeert, wens ik je veel succes met het vinden van de naald in die hooiberg.
Kleinere implementatiebatch = kleinere impactzone.
Bedrijven die CD invoeren, rapporteren volgens het State of DevOps-rapport van 2023 70% minder productiestoringen en een 24x sneller herstel wanneer er wel problemen optreden. De praktijk is inmiddels standaard geworden bij technologiebedrijven van elke omvang.
Praktische tip: Implementeer een aanpak met een "implementatievenster" waarbij teams de implementatiefrequentie geleidelijk verhogen. Begin door van maandelijkse naar wekelijkse implementaties te gaan, vervolgens naar twee keer per week, totdat je de automatisering en het vertrouwen hebt opgebouwd om meerdere keren per dag te implementeren. Richt je op het bouwen van een robuuste testsuite die vóór elke implementatie automatisch wordt uitgevoerd.
Strategie #3: Volledig op afstand (GitLab)
Vóór de pandemie leek de volledig externe structuur van GitLab radicaal. Toch stelde deze het bedrijf in staat om wereldwijd het beste talent aan te trekken en vanaf dag één uitstekende documentatiepraktijken af te dwingen.
Het openbare handboek van GitLab (nu meer dan 15.000 pagina's) werd hun geheime wapen en maakte een einde aan het probleem "Dat wist ik niet" dat veel gedistribueerde teams plaagt. Deze documentatiegerichte aanpak betekende dat nieuwe medewerkers sneller konden worden ingewerkt en dat besluitvorming transparanter werd.
Documentatie schaalt beter dan kennis die binnen een kleine groep blijft. Denk groot!
"Als je niet even iemand op de schouder kunt tikken voor informatie, word je gedwongen alles duidelijk te documenteren," legt Darren Murph, hoofd van werken op afstand bij GitLab, uit. "Hierdoor ontstaat organisatorische veerkracht die kantoorgecentreerde bedrijven zelden bereiken."
Praktische conclusie: Ook als je niet volledig op afstand werkt, kun je een documentatiepraktijk hanteren die op afstand werken als uitgangspunt neemt. Maak een gecentraliseerde kennisbank voor alle belangrijke beslissingen, processen en kennis die binnen de organisatie aanwezig is. Stel als regel dat iets niet bestaat als het niet is gedocumenteerd. Bekijk deze documentatie elk kwartaal om haar actueel te houden.
Strategie #4: Trunkgebaseerde ontwikkeling (Etsy)
Etsy deed afstand van complexe vertakkingsstrategieën ten gunste van een model waarin iedereen regelmatig wijzigingen naar de hoofdcodebasis doorvoert. Deze aanpak zette vraagtekens bij de conventionele opvatting dat ontwikkelaars geïsoleerde functietakken nodig hebben om effectief te kunnen werken.
"We ontdekten dat langlevende takken een vals gevoel van veiligheid creëerden," zegt voormalig Etsy-ingenieur Daniel Schauenberg. "In werkelijkheid stelden ze integratieproblemen alleen maar uit en veroorzaakten ze grotere conflicten wanneer de takken uiteindelijk werden samengevoegd."
Trunkgebaseerde ontwikkeling hielp Etsy om op te schalen van 50 naar meer dan 2.000 ontwikkelaars en toch meer dan 50 keer per dag te implementeren. De aanpak dwong het team om betere geautomatiseerde tests te bouwen, omdat de hoofdtak schoon moest blijven, en maakte een einde aan de maar al te vaak voorkomende "samenvoeghel" waarmee teams bij functietakken te maken krijgen.
Alex merkte een vergelijkbaar patroon op toen hij sprak over AI en codebases met veel context. “Dingen die echt diep gekoppeld zijn aan je eigen systemen… zullen veel mensen vereisen,” zei hij.
In snel veranderende omgevingen moeten teams die rechtstreeks in de trunk werken systeemontwerp en afwegingen grondig begrijpen—want er is minder ruimte om je te verschuilen achter langlevende takken. Het gaat niet alleen om sneller code doorvoeren; het gaat erom dat ingenieurs dichter bij de werkelijke complexiteit staan.
Praktische conclusie: Implementeer functievlaggen om werk in uitvoering te verbergen terwijl je dagelijks wijzigingen naar de hoofdtak doorvoert. Begin met een klein, vertrouwd team om vertrouwen in de aanpak op te bouwen. Stel als teamdoel om minstens één keer per dag wijzigingen naar de hoofdtak door te voeren en meet in de loop der tijd de afname van integratieproblemen.
Je strategie voor functievlaggen is echt belangrijk voor wat je aan je klanten laat zien!
More Articles
Strategie #5: Openbronsoftware als standaard (Hashicorp)
Hashicorp bouwde een bedrijf ter waarde van een miljard dollar door hun belangrijkste infrastructuurtools, zoals Terraform, Vault en Consul, als openbronsoftware beschikbaar te stellen. In tegenstelling tot traditionele bedrijfsmodellen voor software maakte deze strategie snelle adoptie en bijdragen van duizenden ontwikkelaars wereldwijd mogelijk.
"Toen we begonnen, dachten mensen dat we gek waren omdat we onze beste code weggaven," merkt medeoprichter Mitchell Hashimoto op. "Maar we ontdekten dat brede adoptie meer waarde oplevert dan de potentiële licentie-inkomsten die je misloopt."
Voor individuele ontwikkelaars kan het kiezen van de juiste AI-verrijkte tools een vergelijkbare logica volgen. Alex vertelde dat hij onlangs besloot Cursor Pro te kopen omdat “het me gewoon begrijpt, of de stijl begrijpt waarin ik werk.” Net zoals HashiCorp inzette op vertrouwen en aansluiting bij de gemeenschap met openbronsoftware, kiezen ingenieurs nu steeds vaker voor tools die hun werkprocessen intuïtief begrijpen—evenals dat betekent dat ze voor de minder gangbare optie kiezen.
Hun Terraform-tool kreeg meer dan 100.000 GitHub-sterren en werd een industriestandaard—iets wat met een traditionele aanpak met gesloten broncode tientallen jaren zou hebben geduurd. Het bedrijf verdient geld met bedrijfsfuncties, ondersteuning en gehoste diensten, terwijl het de goodwill behoudt van een enorme ontwikkelaarsgemeenschap.
Praktische conclusie: Identificeer onderdelen van je software die baat kunnen hebben bij betrokkenheid van de community. Begin met het open sourcen van een nuttige bibliotheek of tool die niet tot je kern-IP behoort. Bouw een bijdrageproces dat het buitenstaanders gemakkelijk maakt om je code te verbeteren en investeer in goede documentatie om de adoptie te bevorderen.
De gemeenschappelijke rode draad
Wat deze strategieën met elkaar verbindt, is niet alleen lef—het is berekend risico met korte feedbacklussen. Elk team bouwde mechanismen om snel van fouten te leren en de koers bij te stellen.
Alex vertelde hoe AI verandert wat het betekent om ontwikkelaar te zijn. “We worden niet vervangen,” zegt hij, “maar het verantwoordelijkheidsvenster verschuift.”
Sommigen zeggen dat ontwikkelaars steeds meer op productontwikkelaars gaan lijken; anderen voorspellen een splitsing tussen generalisten en specialisten. Hoe dan ook, gedurfde ontwikkelstrategieën slagen vandaag de dag niet alleen dankzij innovatieve tools—ze slagen wanneer teams bereid zijn hun werkprocessen, rollen en manier van denken aan te passen.
Terwijl je je ontwikkelstrategieën opnieuw overweegt, kan het vinden van de juiste partners het verschil maken. Je kunt bijvoorbeeld overwegen samen te werken met een bedrijf voor softwareontwikkeling op maat of een bedrijf voor softwareontwikkeling via nearshoring, bijvoorbeeld.
Abonneer je op de nieuwsbrief van The CTO Club voor meer tips, tools en beste praktijken op het gebied van softwareontwikkeling.
