5 kühne Software-Entscheidungen, die alle für verrückt hielten – bis sie funktionierten
Die Softwareentwicklung ist voll von vertrauten Frameworks—Agile, Wasserfallmodell, Scrum—alles solide Methoden, die Teams dabei helfen, pünktlich und mit weniger Überraschungen zu liefern.
Aber manchmal sind wir so sehr daran gewöhnt, diese ausgetretenen Pfade zu gehen, dass wir vergessen, dass echte Durchbrüche oft passieren, wenn jemand etwas ausprobiert, das auf dem Papier verrückt aussieht. Es ist riskant, klar, aber genau dort verstecken sich meist die größten Erfolge.
„KI ist wirklich gut darin, 70 % der Arbeit schneller zu erledigen,“ sagt Alex Zajac, SDE & AI bei Amazon und Ersteller des Hungry Minds Newsletters. „Aber die letzten 30 % sind am schwierigsten – sie in Produktion zu bringen, Halluzinationen zu verhindern und Evaluations-Grenzen einzuziehen.“
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
Mit anderen Worten: Mutige Softwareentwicklung bedeutet nicht nur, neue Werkzeuge zu verwenden – sondern vor allem, die harte, wenig glamouröse Arbeit zu leisten, sie wirklich zum Laufen zu bringen.
Die meisten Unternehmen halten sich an das altbewährte Vorgehen, weil es als „sicher“ gilt. Niemand wird schief angesehen, wenn eine Idee im Standardprozess fehlschlägt. Laut einer McKinsey-Umfrage aus 2023 sind Unternehmen, die kalkuliertes Risiko fördern, aber 1,7-mal wahrscheinlicher, in Innovationsmetriken besser zu performen als ihre Branchenkollegen.
Und selbst wenn wir wissen, dass mutiges Denken sich auszahlen kann, ist es überraschend selten, wirklich experimentierfreudige Unternehmenskulturen zu finden. Zu wenige Organisationen fördern Risikobereitschaft bei Softwareprojekten explizit.
Frühe Anwender oder sogar wahre Pioniere sind es häufig, die die Spielregeln festlegen, bevor der Rest überhaupt merkt, dass es sie gibt.
Trotz aller Angst und Zurückhaltung gibt es Teams da draußen, die den Sprung ins Ungewisse gewagt und etwas Geniales erreicht haben. Hier sind fünf Strategien, die zunächst ausgefallen oder sogar zu chaotisch wirkten, um Erfolg zu haben.
Strategie #1: Chaos Engineering (Netflix)
Netflix‘ „Chaos Monkey“ bringt absichtlich Systeme in der Produktion zum Absturz, um deren Resilienz zu testen. Klingt verrückt, oder? Doch genau das half Netflix, eine Verfügbarkeit von 99,99 % zu halten, während die Nutzerzahl von 7 auf über 230 Millionen anstieg.
„Wir haben erkannt, dass auf Stabilität zu hoffen keine Strategie ist,“ sagte der ehemalige Netflix-Ingenieur Kolton Andrus. „Indem wir regelmäßig Ausfälle simulierten, hörten unsere Teams auf, Ausfälle zu fürchten, und bauten standardmäßig robustere Systeme.“
Die eigentliche Erkenntnis war kontraintuitiv: Kontrollierte Fehler verhindern tatsächlich katastrophale Ausfälle. Durch das gezielte Testen von Fehlern deckte Netflix Schwachstellen auf, die sonst erst bei einem großen Ausfall aufgefallen wären.
Praxistipp: Starte mit einem „Game Day“, an dem ihr Ausfälle in einer Nicht-Produktionsumgebung simuliert. Wähle einen kritischen Dienst und provoziere einfache Fehler wie das Beenden von Instanzen oder das Unterbrechen von Netzwerkverbindungen. Halte fest, was ausfällt, und behebe diese Schwachstellen, bevor sie in der Realität zu echten Problemen werden.
Strategie #2: Kontinuierliche Bereitstellung (Flickr)
2009, als die meisten Unternehmen monatlich auslieferten, sorgte Flickrs Präsentation „10 Deployments am Tag“ für Furore. Teams befürchteten, dass kleinere, häufigere Releases zu Chaos führen würden, aber Flickr stellte fest: Häufigere Releases verringern das Risiko drastisch.
Die Rechnung ist einfach, aber wirkungsvoll: Wenn du 5–10 Änderungen auf einmal verteilst, ist es leicht, Probleme zu isolieren. Wenn du nach einem Monat 500 Änderungen einspielst, viel Glück beim Suchen der Nadel im Heuhaufen.
Kleinere Deployment-Batches = geringerer Einschlagsbereich.
Unternehmen, die Continuous Deployment nutzen, berichten laut State-of-DevOps-Report 2023 von 70 % weniger Produktionsausfällen und 24-mal schnellerer Wiederherstellung, wenn doch mal ein Fehler auftritt. Heute ist die Praxis branchenweit Standard bei Tech-Unternehmen jeder Größe.
Praxistipp: Implementiere ein „Deployment-Window“-Verfahren, bei dem Teams die Auslieferungshäufigkeit schrittweise steigern. Beginnt mit monatlichen und wechselt zu wöchentlichen Deployments, dann zweiwöchentlich, bis ihr die nötige Automatisierung und Sicherheit habt, mehrmals täglich auszuliefern. Konzentriere dich auf die Entwicklung eines robusten Test-Suites, das vor jedem Deployment automatisch durchläuft.
Strategie #3: Voll-Remote-Modell (GitLab)
Vor der Pandemie erschien GitLabs komplett dezentrale Struktur radikal. Dennoch ermöglichte sie dem Unternehmen, weltweit das beste Talent anzuziehen und von Anfang an exzellente Dokumentationspraktiken zu etablieren.
Das öffentliche Handbuch von GitLab (mittlerweile über 15.000 Seiten) wurde zur Geheimwaffe des Unternehmens und eliminierte das "Das wusste ich nicht"-Problem, das viele verteilte Teams plagt. Dieser Dokumentations-First-Ansatz ermöglichte es neuen Mitarbeitenden, sich schneller einzuarbeiten, und machte Entscheidungsprozesse transparenter.
Dokumentation skaliert besser als Stammeswissen. Denke groß!
"Wenn man nicht einfach jemanden auf die Schulter tippen kann, ist man gezwungen, alles klar zu dokumentieren," erklärt Darren Murph, Head of Remote bei GitLab. "Das schafft eine organisatorische Widerstandsfähigkeit, die Unternehmen mit Präsenzkultur selten erreichen."
Praxistipp: Auch wenn Sie nicht vollständig remote arbeiten, sollten Sie eine "remote-first"-Dokumentationspraxis einführen. Erstellen Sie eine zentrale Wissensdatenbank für alle wichtigen Entscheidungen, Prozesse und Stammeswissen. Legen Sie die Regel fest: Was nicht dokumentiert ist, existiert nicht. Überprüfen Sie diese Dokumentation vierteljährlich, um sie aktuell zu halten.
Strategie #4: Trunk-basiertes Development (Etsy)
Etsy verabschiedete sich von komplexen Branching-Strategien und setzte stattdessen auf ein Modell, bei dem alle regelmäßig direkt am Haupt-Codebase arbeiten. Dieser Ansatz stellte die gängige Meinung infrage, dass Entwickler isolierte Feature-Branches brauchen, um effektiv zu arbeiten.
"Wir stellten fest, dass langlebige Branches nur eine trügerische Sicherheit suggerierten," sagt der ehemalige Etsy-Ingenieur Daniel Schauenberg. "In Wirklichkeit verzögerten sie nur Integrationsschmerzen und führten zu größeren Konflikten beim endgültigen Zusammenführen."
Durch trunk-basiertes Development konnte Etsy von 50 auf über 2.000 Entwickler skalieren und dennoch mehr als 50 Deployments täglich durchführen. Der Ansatz zwang das Team, bessere automatisierte Tests zu entwickeln, da der Haupt-Branch stets stabil bleiben musste, und er eliminierte das allzu bekannte "Merge-Hell", das bei Feature-Branches häufig auftritt.
Alex stellte ein ähnliches Muster fest, als er über KI und kontextreiche Codebasen sprach. „Dinge, die wirklich tief mit deinen proprietären Systemen verzahnt sind... werden viele Menschen benötigen,“ sagte er.
In schnelllebigen Umgebungen müssen Teams, die direkt im Trunk arbeiten, Systemdesign und Abwägungen sehr gut verstehen – denn es gibt weniger Möglichkeiten, sich hinter lang laufenden Branches zu verstecken. Es geht nicht nur darum, Code schneller zu committen; vielmehr stehen die Entwickler der realen Komplexität viel näher.
Praxistipp: Implementieren Sie Feature-Toggles, um unfertige Funktionen zu verbergen, während Sie täglich zum Haupt-Branch committen. Beginnen Sie mit einem kleinen, vertrauenswürdigen Team, um Vertrauen in den Ansatz aufzubauen. Setzen Sie sich als Team das Ziel, mindestens einmal täglich zum Haupt-Branch zu committen, und messen Sie, wie die Integrationsprobleme im Laufe der Zeit abnehmen.
Deine Strategie für Feature-Toggling ist entscheidend dafür, was du deinen Kunden präsentierst!
Strategie #5: Open Source als Standard (Hashicorp)
Hashicorp baute ein Milliarden-Dollar-Unternehmen auf, indem sie ihre wichtigsten Infrastruktur-Tools wie Terraform, Vault und Consul als Open Source bereitstellten. Im Gegensatz zu traditionellen Software-Geschäftsmodellen ermöglichte diese Strategie eine schnelle Verbreitung und Beiträge von Tausenden Entwicklern weltweit.
"Als wir anfingen, hielten uns viele für verrückt, unser bestes Code offen abzugeben," erzählt Mitchell Hashimoto, Mitgründer. "Aber wir haben festgestellt, dass breite Akzeptanz mehr Wert schafft, als potenzielle Lizenzgebühren je einbringen könnten."
Auch einzelne Entwickler können bei der Auswahl KI-gestützter Werkzeuge einer ähnlichen Logik folgen. Alex erzählte, dass er sich jüngst für den Kauf von Cursor Pro entschieden hat, weil „es mich einfach versteht oder den Stil erkennt, mit dem ich arbeite.“ Wie HashiCorp auf Vertrauen und Community-Passung beim Open Source setzte, greifen Ingenieure heute zu Tools, die ihre Arbeitsweise intuitiv unterstützen – selbst wenn das weniger Mainstream ist.
Ihr Tool Terraform erreichte über 100.000 GitHub-Sterne und wurde zum Branchenstandard – etwas, das mit einem herkömmlichen Closed-Source-Ansatz Jahrzehnte gedauert hätte. Das Unternehmen verdient Geld mit Enterprise-Funktionen, Support und gehosteten Diensten und erhält sich dennoch die Wertschätzung einer riesigen Entwickler-Community.
Praktische Empfehlung: Identifizieren Sie Komponenten Ihrer Software, die von einer Beteiligung der Community profitieren könnten. Starten Sie, indem Sie eine hilfreiche Bibliothek oder ein Tool, das nicht Ihr Kerngeschäft ist, als Open Source bereitstellen. Entwickeln Sie einen Beitragsprozess, der es Externen leicht macht, Ihren Code zu verbessern, und investieren Sie in eine gute Dokumentation, um die Übernahme zu erleichtern.
Der gemeinsame Nenner
Was diese Strategien verbindet, ist nicht nur Mut – es handelt sich um kalkuliertes Risiko mit kurzen Feedbackschleifen. Jedes Team hat Mechanismen entwickelt, um schnell aus Fehlern zu lernen und Kurskorrekturen vorzunehmen.
Alex erwähnte, wie KI das Verständnis der Rolle eines Entwicklers verändert. „Wir werden nicht ersetzt“, sagt er, „aber das Fenster der Verantwortung verschiebt sich."
Manche sagen, Entwickler ähneln immer mehr Produktingenieuren; andere prognostizieren eine Aufspaltung zwischen Generalisten und Spezialisten. Wie auch immer – mutige Entwicklungsstrategien sind heute nicht nur wegen innovativer Werkzeuge erfolgreich, sondern auch, weil Teams bereit sind, ihre Arbeitsabläufe, Rollen und Denkweisen anzupassen.
Wenn Sie Ihre Entwicklungsstrategien überdenken, kann die Wahl der richtigen Partner entscheidend sein. Sie könnten beispielsweise mit einem maßgeschneiderten Softwareentwicklungsunternehmen oder einem Nearshore-Softwareentwicklungsunternehmen zusammenarbeiten.
Abonnieren Sie den Newsletter des CTO Club für weitere Tipps, Tools und Best Practices zur Softwareentwicklung.
