5 mutige Schritte in der Softwareentwicklung, die alle für verrückt hielten – bis sie funktionierten
Die Softwareentwicklung ist voller bekannter Frameworks – Agile Entwicklung, Wasserfallmodell, Scrum – allesamt solide Optionen, die Teams dabei helfen, pünktlich und mit weniger Überraschungen zu liefern.
Aber manchmal fühlen wir uns so wohl dabei, diesen ausgetretenen Pfaden zu folgen, dass wir vergessen: Wirkliche Durchbrüche entstehen oft, wenn jemand etwas ausprobiert, das auf dem Papier verrückt aussieht. Riskant ist es sicherlich, aber genau dort verstecken sich normalerweise die großen 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 diese letzten 30 % sind am schwierigsten – sie in die Produktion zu bringen, sicherzustellen, dass sie nicht halluziniert, und Bewertungsleitplanken einzurichten.“
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Mit anderen Worten: Mutige Softwareentwicklung dreht sich nicht nur um den Einsatz neuer Werkzeuge – es geht darum, die schwierige, wenig glamouröse Arbeit zu leisten, damit sie wirklich funktionieren.
Die meisten Unternehmen halten sich an das übliche Vorgehen, weil es als „sicher“ gilt. Niemand wird dafür verantwortlich gemacht, einen unkonventionellen Weg eingeschlagen zu haben, wenn eine Idee in einem Standardprozess nicht aufgeht. Laut einer McKinsey-Umfrage aus dem Jahr 2023 ist es jedoch 1,7-mal wahrscheinlicher, dass Unternehmen, die kalkulierte Risikobereitschaft fördern, ihre Branchenkollegen bei Innovationskennzahlen übertreffen.
Und selbst wenn wir wissen, dass mutiges Denken sich auszahlen kann, findet man überraschend selten Umgebungen, die Experimente wirklich belohnen. Zu wenige Organisationen ermutigen ausdrücklich dazu, bei Softwareprojekten Risiken einzugehen.
Frühe Anwender oder manchmal auch echte Pioniere können die Regeln oft festlegen, bevor alle anderen überhaupt wissen, dass es sie gibt.
Trotz all der Angst und des Zögerns gibt es Teams, die einen gewaltigen Sprung gewagt und etwas Brillantes geschaffen haben. Hier sind fünf Strategien, die zunächst unkonventionell – oder vielleicht zu chaotisch – wirkten, um erfolgreich zu sein.
Strategie Nr. 1: Chaos-Engineering (Netflix)
Netflix’ „Chaos Monkey“ legt absichtlich Systeme in der Produktion lahm, um ihre Widerstandsfähigkeit zu testen. Klingt verrückt, oder? Doch dieser Ansatz half Netflix dabei, eine Verfügbarkeit von 99,99 % aufrechtzuerhalten, während das Unternehmen von 7 Millionen auf über 230 Millionen Abonnenten wuchs.
„Wir erkannten, dass auf Stabilität zu hoffen keine Strategie war“, sagte der ehemalige Netflix-Ingenieur Kolton Andrus. „Indem wir regelmäßig Ausfälle provozierten, hörten unsere Teams auf, Ausfälle zu fürchten, und entwickelten standardmäßig robustere Systeme.“
Die entscheidende Erkenntnis war kontraintuitiv: Das Erzeugen kontrollierter Ausfälle verhinderte tatsächlich katastrophale Ausfälle. Netflix’ Tests zur Einschleusung von Fehlern deckten Schwachstellen auf, die verborgen geblieben wären, bis ein größerer Ausfall eingetreten wäre.
Konkrete Empfehlung: Beginnen Sie mit einem „Spieletag“, an dem Sie Ausfälle in einer Nicht-Produktionsumgebung simulieren. Wählen Sie einen kritischen Dienst aus und führen Sie einfache Fehler ein, etwa indem Sie Instanzen beenden oder Netzwerkverbindungen unterbrechen. Dokumentieren Sie, was ausfällt, und beheben Sie diese Schwachstellen, bevor sie echte Probleme verursachen.
Strategie Nr. 2: Kontinuierliche Bereitstellung (Flickr)
Als die meisten Unternehmen im Jahr 2009 monatlich bereitstellten, sorgte Flickrs Präsentation „10 Bereitstellungen pro Tag“ für großes Staunen. Die Teams befürchteten, dass kleinere, häufigere Veröffentlichungen Chaos verursachen würden, doch Flickr stellte das Gegenteil fest: Häufigere Veröffentlichungen reduzierten das Risiko tatsächlich erheblich.
Die Rechnung ist einfach, aber wirkungsvoll: Wenn Sie 5–10 Änderungen auf einmal bereitstellen, lassen sich Probleme leicht isolieren. Wenn Sie nach einem Monat 500 Änderungen bereitstellen, viel Glück bei der Suche nach der Nadel im Heuhaufen.
Kleinere Bereitstellungseinheiten = geringerer Schadensradius.
Unternehmen, die CD einführen, berichten laut dem State-of-DevOps-Bericht 2023 von 70 % weniger Fehlern in der Produktion und einer 24-mal schnelleren Wiederherstellung, wenn doch einmal Probleme auftreten. Die Praxis ist inzwischen bei Technologieunternehmen jeder Größe zum Standard geworden.
Konkrete Empfehlung: Führen Sie einen Ansatz mit „Bereitstellungsfenstern“ ein, bei dem Teams die Häufigkeit von Bereitstellungen schrittweise erhöhen. Beginnen Sie damit, von monatlichen auf wöchentliche Bereitstellungen umzustellen, anschließend auf zweimal wöchentlich, bis Sie die Automatisierung und das Vertrauen aufgebaut haben, um mehrmals täglich bereitzustellen. Konzentrieren Sie sich auf den Aufbau einer robusten Testsuite, die vor jeder Bereitstellung automatisch ausgeführt wird.
Strategie Nr. 3: Vollständig verteiltes Modell (GitLab)
Vor der Pandemie wirkte GitLabs vollständig verteilte Struktur radikal. Dennoch ermöglichte sie dem Unternehmen, weltweit die besten Talente einzustellen, und zwang es von Anfang an zu hervorragenden Dokumentationspraktiken.
Das öffentliche Handbuch von GitLab (inzwischen über 15.000 Seiten) wurde zu ihrer Geheimwaffe und beseitigte das Problem „Das wusste ich nicht“, das viele verteilte Teams plagt. Dieser dokumentationsorientierte Ansatz ermöglichte es neuen Mitarbeitenden, sich schneller einzuarbeiten, und machte die Entscheidungsfindung transparenter.
Dokumentation lässt sich besser skalieren als Erfahrungswissen. Denkt groß!
„Wenn man niemanden wegen einer Information kurz über die Schulter hinweg fragen kann, ist man gezwungen, alles klar zu dokumentieren“, erklärt Darren Murph, der Leiter des Bereichs Remote bei GitLab. „Das schafft eine organisatorische Widerstandsfähigkeit, die bürozentrierte Unternehmen nur selten erreichen.“
Konkrete Empfehlung: Auch wenn ihr nicht vollständig remote arbeitet, führt eine Dokumentationspraxis nach dem Prinzip „Remote an erster Stelle“ ein. Erstellt eine zentrale Wissensdatenbank für alle wichtigen Entscheidungen, Prozesse und Erfahrungswerte. Legt fest, dass etwas nicht existiert, wenn es nicht dokumentiert ist. Überprüft diese Dokumentation vierteljährlich, damit sie aktuell bleibt.
Strategie Nr. 4: Entwicklung auf dem Hauptzweig (Etsy)
Etsy verabschiedete sich von komplexen Verzweigungsstrategien zugunsten eines Modells, bei dem alle regelmäßig Änderungen am zentralen Codebestand vornehmen. Dieser Ansatz stellte die gängige Annahme infrage, dass Entwickler isolierte Funktionszweige benötigen, um effektiv zu arbeiten.
„Wir stellten fest, dass langlebige Zweige ein falsches Gefühl der Sicherheit erzeugten“, sagt der ehemalige Etsy-Ingenieur Daniel Schauenberg. „Tatsächlich verzögerten sie lediglich die Integrationsprobleme und führten zu größeren Konflikten, wenn die Zweige schließlich zusammengeführt wurden.“
Die Entwicklung auf dem Hauptzweig half Etsy, von 50 auf mehr als 2.000 Entwickler zu wachsen und weiterhin über 50-mal täglich bereitzustellen. Der Ansatz zwang das Team, bessere automatisierte Tests zu entwickeln, da der Hauptzweig sauber bleiben musste, und beseitigte die allzu häufige „Zusammenführungshölle“, mit der Teams bei Funktionszweigen konfrontiert sind.
Alex bemerkte ein ähnliches Muster, als er über KI und kontextintensive Codebasen sprach. „Dinge, die sehr eng an eure proprietären Systeme gekoppelt sind … werden viele Menschen erfordern“, sagte er.
In schnelllebigen Umgebungen müssen Teams, die direkt im Hauptzweig arbeiten, Systemdesign und Zielkonflikte tiefgehend verstehen – denn es gibt weniger Möglichkeiten, sich hinter langlebigen Zweigen zu verstecken. Es geht nicht nur darum, Code schneller zu übertragen, sondern darum, dass Ingenieure der tatsächlichen Komplexität näher sind.
Konkrete Empfehlung: Implementiert Funktionsschalter, um unfertige Arbeiten zu verbergen, während ihr täglich Änderungen am Hauptzweig vornehmt. Beginnt mit einem kleinen, vertrauenswürdigen Team, um Vertrauen in den Ansatz aufzubauen. Setzt euch als Team das Ziel, mindestens einmal täglich Änderungen am Hauptzweig vorzunehmen, und messt im Laufe der Zeit die Verringerung von Integrationsproblemen.
Eure Strategie für Funktionsschalter ist besonders wichtig im Hinblick darauf, was ihr euren Kunden zeigt!
More Articles
Strategie Nr. 5: Quelloffenheit als Standard (Hashicorp)
Hashicorp baute ein Unternehmen mit einem Umsatz von einer Milliarde Dollar auf, indem das Unternehmen seine zentralen Infrastrukturwerkzeuge wie Terraform, Vault und Consul als quelloffene Software veröffentlichte. Im Gegensatz zu herkömmlichen Geschäftsmodellen für Software ermöglichte diese Strategie eine schnelle Verbreitung und Beiträge von Tausenden Entwicklern weltweit.
„Als wir anfingen, hielten die Menschen uns für verrückt, weil wir unseren besten Code kostenlos zur Verfügung stellten“, merkt Mitbegründer Mitchell Hashimoto an. „Wir stellten jedoch fest, dass eine breite Nutzung mehr Wert schafft, als man an möglichen Lizenzeinnahmen verliert.“
Für einzelne Entwickler kann die Auswahl der richtigen KI-gestützten Werkzeuge einer ähnlichen Logik folgen. Alex berichtete, dass er sich kürzlich für den Kauf von Cursor Pro entschieden habe, weil es „mich einfach versteht oder den Stil versteht, mit dem ich arbeite“. So wie HashiCorp bei quelloffener Software auf Vertrauen und die Passung zur Community setzte, wenden sich Ingenieure nun intuitiv den Werkzeugen zu, die ihre Arbeitsabläufe verstehen – selbst wenn sie sich damit für die weniger verbreitete Option entscheiden.
Ihr Terraform-Werkzeug erhielt mehr als 100.000 GitHub-Sterne und wurde zum Branchenstandard – etwas, das mit einem traditionellen proprietären Ansatz Jahrzehnte gedauert hätte. Das Unternehmen erzielt Einnahmen durch Unternehmensfunktionen, Unterstützung und bereitgestellte Dienste und bewahrt sich zugleich das Wohlwollen einer riesigen Entwickler-Community.
Umsetzbare Erkenntnis: Identifizieren Sie Komponenten Ihrer Software, die von der Beteiligung der Community profitieren könnten. Beginnen Sie damit, eine hilfreiche Bibliothek oder ein nützliches Tool als Open-Source-Projekt zu veröffentlichen, das nicht zu Ihrem geistigen Kerneigentum gehört. Entwickeln Sie einen Beitragsprozess, der es Außenstehenden erleichtert, Ihren Code zu verbessern, und investieren Sie in eine gute Dokumentation, um die Nutzung zu fördern.
Der gemeinsame Nenner
Was diese Strategien verbindet, ist nicht nur Mut – es ist kalkuliertes Risiko mit engen Feedbackschleifen. Jedes Team entwickelte Mechanismen, um schnell aus Fehlern zu lernen und den Kurs zu korrigieren.
Alex erwähnte, wie KI verändert, was es bedeutet, Entwickler zu sein. „Wir werden nicht ersetzt,“ sagt er, „aber das gleitende Verantwortungsfenster verschiebt sich.“
Manche sagen, dass Entwickler eher zu Produktentwicklern werden; andere prognostizieren eine Aufspaltung zwischen Generalisten und Spezialisten. Wie dem auch sei: Mutige Entwicklungsstrategien sind heute nicht nur wegen innovativer Tools erfolgreich – sie sind erfolgreich, wenn Teams bereit sind, ihre Arbeitsabläufe, Rollen und Denkweisen anzupassen.
Wenn Sie Ihre Entwicklungsstrategien überdenken, können die richtigen Partner den entscheidenden Unterschied machen. Sie könnten beispielsweise mit einem Unternehmen für kundenspezifische Softwareentwicklung oder einem Unternehmen für Softwareentwicklung in nahegelegenen Ländern zusammenarbeiten, zum Beispiel.
Abonnieren Sie den Newsletter von The CTO Club für weitere Tipps, Tools und bewährte Verfahren zur Softwareentwicklung.
