5 gedurfde stappen in softwareontwikkeling die iedereen gek noemde—totdat ze werkten
Softwareontwikkeling zit vol vertrouwde raamwerken—Agile, Watervalmodel, Scrum—allemaal solide keuzes die teams helpen op tijd te leveren en met minder verrassingen.
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 belachelijk uitziet. Het is riskant, zeker, maar daar zitten meestal de grote successen verborgen.
“AI is er heel 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 nemen, ervoor zorgen dat het niet hallucineert en evaluatiewaarborgen instellen.”
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
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 dat als “veilig” wordt gezien. Niemand krijgt de schuld als een idee niet uitpakt binnen een standaardproces. Volgens een enquête van McKinsey uit 2023 is de kans echter 1,7x groter dat bedrijven die het nemen van berekende risico’s aanmoedigen, beter presteren dan branchegenoten op het gebied van innovatiemaatstaven.
En zelfs als we weten dat gedurfd denken resultaat kan opleveren, 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, mogen vaak de regels bepalen voordat alle anderen überhaupt weten dat ze bestaan.
Ondanks alle angst en aarzeling zijn er teams die een enorme sprong in het diepe hebben gewaagd en op iets briljants zijn uitgekomen. Hier zijn vijf strategieën die aanvankelijk ongebruikelijk—of misschien te chaotisch—leken om succesvol te zijn.
Strategie #1: Chaos-engineering (Netflix)
Netflix' "Chaos Monkey" brengt opzettelijk verstoringen aan in systemen in productie om de veerkracht te testen. Klinkt krankzinnig, toch? Maar deze aanpak hielp Netflix een beschikbaarheid van 99,99% te behouden terwijl het bedrijf groeide van 7 miljoen naar meer dan 230 miljoen abonnees.
"We beseften dat hopen op stabiliteit geen strategie was," zei voormalig Netflix-ingenieur Kolton Andrus. "Door regelmatig storingen te injecteren, 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, voorkwamen we juist catastrofale storingen. Netflix' tests met het injecteren van storingen brachten zwakke plekken aan het licht die verborgen zouden zijn gebleven totdat er een grote uitval plaatsvond.
Praktische tip: Begin met een "Speldag" waarin je storingen simuleert in een omgeving die niet productie is. Kies één kritieke service en introduceer eenvoudige storingen, zoals het beëindigen van instanties of het verbreken van netwerkverbindingen. Documenteer wat er stukgaat en verhelp die kwetsbaarheden voordat ze echte problemen veroorzaken.
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 drastisch.
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, succes met het vinden van de naald in die hooiberg.
Kleinere implementatiebundels = kleinere impact.
Bedrijven die CD invoeren, melden volgens het rapport over de staat van DevOps uit 2023 70% minder productiestoringen en een 24x sneller herstel wanneer er wel problemen optreden. De praktijk is sindsdien 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, daarna naar twee keer per week, totdat je over de automatisering en het vertrouwen beschikt 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: Model voor volledig werken op afstand (GitLab)
Vóór de pandemie leek de volledig externe structuur van GitLab radicaal. Toch stelde die het bedrijf in staat 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" waar veel gedistribueerde teams mee kampen. Deze documentatie-eerst-aanpak betekende dat nieuwe medewerkers sneller konden worden ingewerkt en dat besluitvorming transparanter werd.
Documentatie schaalt beter dan kennis die alleen binnen de organisatie wordt doorgegeven. 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 verantwoordelijke voor werken op afstand bij GitLab, uit. "Dit zorgt voor organisatorische veerkracht die kantoorgeoriënteerde bedrijven zelden bereiken."
Direct toepasbare tip: Ook als je niet volledig op afstand werkt, kun je een documentatiepraktijk hanteren waarbij werken op afstand vooropstaat. Maak een gecentraliseerde kennisbank voor alle belangrijke beslissingen, processen en kennis die alleen binnen de organisatie wordt doorgegeven. Stel als regel dat iets niet bestaat als het niet is gedocumenteerd. Controleer deze documentatie elk kwartaal om haar actueel te houden.
Strategie #4: Ontwikkeling op basis van de hoofdbranch (Etsy)
Etsy deed afstand van complexe branchstrategieën ten gunste van een model waarin iedereen regelmatig wijzigingen naar de hoofdcodebasis doorvoert. Deze aanpak ging in tegen de conventionele wijsheid dat ontwikkelaars geïsoleerde featurebranches nodig hebben om effectief te kunnen werken.
"We ontdekten dat langlevende branches een vals gevoel van veiligheid creëerden," zegt voormalig Etsy-engineer Daniel Schauenberg. "In werkelijkheid stelden ze integratieproblemen alleen maar uit en veroorzaakten ze grotere conflicten wanneer branches uiteindelijk werden samengevoegd."
Ontwikkeling op basis van de hoofdbranch hielp Etsy groeien van 50 naar meer dan 2.000 ontwikkelaars, terwijl er nog steeds meer dan 50 keer per dag werd uitgerold. De aanpak dwong het team om betere geautomatiseerde tests te bouwen, omdat de hoofdbranch schoon moest blijven, en maakte een einde aan de al te vaak voorkomende "samenvoeghel" waar teams met featurebranches mee 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 nodig hebben,” zei hij.
In snel veranderende omgevingen moeten teams die rechtstreeks in de hoofdbranch werken systeemontwerp en afwegingen grondig begrijpen—omdat er minder ruimte is om je achter langlevende branches te verschuilen. Het gaat niet alleen om sneller code doorvoeren; het gaat erom dat ontwikkelaars dichter bij de werkelijke complexiteit staan.
Direct toepasbare tip: Implementeer functievlaggen om werk in uitvoering te verbergen terwijl je dagelijks wijzigingen naar de hoofdbranch 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 hoofdbranch door te voeren en meet na verloop van tijd de afname van integratieproblemen.
Je strategie voor functievlaggen is echt belangrijk voor wat je aan je klanten laat zien!
More Articles
Strategie #5: Standaard openbronsoftware (Hashicorp)
Hashicorp bouwde een miljardenbedrijf op 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 creëert dan de potentiële licentie-inkomsten die je misloopt."
Voor individuele ontwikkelaars kan het kiezen van de juiste AI-ondersteunde tools een vergelijkbare logica volgen. Alex vertelde dat hij onlangs voor Cursor Pro koos omdat “het mij gewoon begrijpt, of de stijl begrijpt waarin ik werk.” Net zoals HashiCorp inzette op vertrouwen en aansluiting bij de gemeenschap met openbronsoftware, kiezen ontwikkelaars 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 enterprisefuncties, ondersteuning en gehoste diensten, terwijl het de goodwill behoudt van een enorme gemeenschap van ontwikkelaars.
Direct toepasbare conclusie: Identificeer onderdelen van je software die baat kunnen hebben bij betrokkenheid van de community. Begin met het opensourcen van een nuttige bibliotheek of tool die niet tot je kernintellectueel eigendom behoort. Bouw een proces voor bijdragen dat het buitenstaanders gemakkelijk maakt je code te verbeteren en investeer in goede documentatie om de toepassing ervan te bevorderen.
De gemeenschappelijke noemer
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 verschuivende verantwoordelijkheidsvenster verandert.”
Sommigen zeggen dat ontwikkelaars steeds meer op productingenieurs 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.
Als je je ontwikkelstrategieën opnieuw bekijkt, kunnen de juiste partners het verschil maken. Je kunt bijvoorbeeld overwegen samen te werken met een bedrijf voor maatwerksoftwareontwikkeling of een nearshorebedrijf voor softwareontwikkeling, bijvoorbeeld.
Abonneer je op de nieuwsbrief van The CTO Club voor meer tips, tools en best practices op het gebied van softwareontwikkeling.
