Bruce Lee über DevOps: Beherrscht eure Tools, liefert bessere Software

Bruce Lee sagte einmal: "Ich fürchte nicht den Mann, der 10.000 Tritte trainiert hat. Ich fürchte den Mann, der einen einzigen Tritt 10.000 Mal trainiert hat." In der Kampfkunst – und in der Technik – gibt es immer die Versuchung, dem Neuen nachzujagen. Eine andere Bewegung, eine andere Waffe, eine andere glänzende Technik, die einen Vorteil verspricht. Aber dieser Drang lenkt oft von dem ab, was wirklich wichtig ist: Die Beherrschung der Grundlagen.

Insgesamt kann der Kampfsportler die notwendige Basisarbeit und die erforderliche Präzision aus den Augen verlieren. Es nützt nichts, mehr Tritttechniken zu trainieren, wenn man die Tritte, die man kennt, nicht auf ein Niveau gebracht hat, auf dem sie wirklich nützlich sind.

Mehr zu trainieren, anstatt die vorhandenen Fähigkeiten zu perfektionieren, bedeutet, dass der Kampfsportler seine kostbare Trainingszeit vergeudet. Es wäre vielleicht sogar besser für ihn, die Zeit zu nutzen und eine ganz andere Sportart zu betreiben, als sich von seinem Hauptziel ablenken zu lassen: besser im Kampfsport zu werden.

Das Äquivalent von 10.000 Tritten in Tech-Unternehmen

In den meisten modernen DevOps- und Engineering-Teams werden neue Tools zu schnell und ohne ausreichende Überlegung eingeführt, oft zum Nachteil des kundenorientierten Produkts. Zeit und Ressourcen sind begrenzt, und sie für das falsche Thema auszugeben, wirkt sich direkt auf die Produktqualität aus.

Ein anschauliches Beispiel: Ein Team betrieb ursprünglich nur wenige, kleine Dienste auf virtuellen Maschinen. Dabei handelte es sich um einfache Python-Skripte in Docker-Containern auf einem stabilen Ubuntu-System. Wartung und Updates waren unkompliziert – jeder mit Grundkenntnissen in Ubuntu und Python konnte sie problemlos durchführen.

Dann entschied sich das Team, die Dienste in die Cloud zu migrieren – auf Kubernetes, weil es „einfach großartig“ klang. Dafür wurden neue Automatisierungsebenen und zusätzliche Tools eingeführt, mit denen die meisten Teammitglieder kaum vertraut waren. Um Kubernetes voll auszunutzen, ersetzte man die VMs durch ein Virtual Scale Set und ergänzte redundanten Netzwerkspeicher; zusätzlich kamen Azure-Komponenten und ein neues Monitoring-Backend samt Datenbank hinzu.

Plötzlich erforderte die Behebung kleinster Probleme ein Vielfaches an Spezialwissen. Eine Wissensinsel entstand, da nur wenige im Team den Überblick behielten. Die Entwicklung verlangsamte sich merklich, Fehleranalysen dauerten Stunden oder gar Tage – ohne erkennbaren Mehrwert für das Produkt, aber mit massivem Produktivitätsverlust.

Ein weiteres sehr typisches Muster betrifft Jenkins: Stellt euch ein Unternehmen vor, das das allseits beliebte Jenkins in der typischen, veralteten Installation hat. Das Team beschließt, auf GitHub umzusteigen, aber da die alten Pipelines kompliziert sind, findet es nie die Zeit, sie alle umzustellen. Jetzt sind also zwei Pipelinesysteme im Einsatz. Irgendwann wechseln ein paar andere Teams von GitHub zu Azure DevOps, was das Hipster-Team dazu ermutigt, für seine eigene Lösung zu plädieren, von der noch nie jemand gehört hat, die aber angeblich alle Probleme löst, weil sie neu, klein und glänzend ist.

Zu diesem Zeitpunkt ist Jenkins immer noch ein Problem, das genau die gleiche Menge an Engagement erfordert, und obendrein haben die Teams Wissensinseln und Barrieren geschaffen.

Sollten wir also alle zu Perl zurückkehren?

Wir könnten endlose Beispiele anführen, und sie würden alle vertraut wirken: Neue Programmiersprachen, zusätzliche Monitoring-Tools, weitere Cloud-Anbieter, neue Automatisierungs-Tools oder gar ein kompletter Tech-Stack-Wechsel, nur weil der neue „besser“ sein soll – ohne dass es tatsächlich klar ist.

Ich plädiere nicht dafür, aus nostalgischen Gründen nur Perl auf Unix zu verwenden. Doch häufig führt eine Erweiterung oder Migration des Tech-Stacks nicht zu den gewünschten Ergebnissen und kann sogar unerwünschte Nebenwirkungen erzeugen. Perl/Unix-Profis kennen jeden Winkel ihrer Umgebung – ein Wissen, das sonst kaum jemand erreicht.

In mehreren Unternehmen habe ich erlebt, dass gerade ein begrenzter Tech-Stack Teams befähigt, Code, Infrastruktur und Produkt über Abteilungsgrenzen hinweg wirklich zu verstehen. Diese Unternehmen waren die einzigen, die ich als wirklich agil erlebt habe.

Als Berater prüfe ich daher oft die Anzahl der eingesetzten Tools als Reifegrad-Indikator: Wird eine kleine, wohlüberlegte Auswahl genutzt, um maximalen Nutzen zu erzielen, oder herrscht eine Tool-Anarchie? In der Praxis ist es selten Schwarz oder Weiß – doch der Unterschied wirkt sich direkt auf Produktivität und Übersicht aus.

Warum nicht neue Tools hinzufügen

Eine kurze Liste von Dingen, die sich verschlechtern können, wenn man etwas Neues zum Stack hinzufügt, umfasst Komplexität, Produktivität, Wartbarkeit, Teamfokus und Wissensaustausch.

Komplexität: Der stille Killer der modernen Technik

Komplexität untergräbt die Produktivität oft schneller als schlechter Code. Es ist gefährlich, die DevOps-Toolchain unkontrolliert wachsen zu lassen, bis niemand mehr den Überblick behält. Jedes neue Tool bringt versteckte Kosten mit sich: zusätzliche Infrastruktur, neue Datenbanken, Build-Systeme, Paketmanager, Wissenserwerb, Ablösung alter Tools, Datenmigration – all das summiert sich schnell.

Ein erfahrener Ingenieur sagte einmal: „Die Reduzierung von Komplexität ist die wichtigste Aufgabe jedes Leiters.“ Und das stimmt. Viele moderne Unternehmen haben diesen Kampf verloren: Sie sind langsamer, weniger stabil, Fehlerbehebung dauert länger, und die Entwicklung wird teuer. Statt neue Komplexitätsschichten aufzubauen, sollten sie den Fokus auf vereinfachen und verschlanken legen.

Produktivität: Die versteckten Kosten der Einführung eines neuen Tools.

Die Einführung eines neuen Tools bringt zunächst offensichtliche Kosten mit sich: Vor allem Zeitaufwand.

Doch die versteckten Kosten sind oft noch größer. Mit wachsender Komplexität steigt die kognitive Belastung der Ingenieure. Wartung, Dokumentation und die Übersicht darüber, welches Tool wann und wofür genutzt wird, verdoppeln sich schnell. Kleine Details summieren sich zu einem großen Problem.

Ein typisches Beispiel: Ein Unternehmen mit mehreren Wissensdatenbanken. Wenn Informationen im falschen Tool gesucht werden, geht Produktivität verloren – und die Gefahr steigt, dass Fehler passieren oder falsche Entscheidungen getroffen werden.

Kurzum: Zu viel Komplexität kann die Produktivität massiv bremsen.

Wartbarkeit: Wenn niemand dafür zuständig ist, wird es kaputt gehen.

Jedes neue Tool braucht Pflege – sei es durch ein internes Team oder durch ausgelagerte Unterstützung. In jedem Fall entstehen direkte Kosten in Zeit und Geld, die nicht einfach verschwinden. Selbst bei SaaS-Lösungen ist die Abschaltung oft nur theoretisch möglich, sobald das Tool in den Entwicklungs-Workflow integriert ist.

Die IT-Abteilung hat oft den Ruf, Wartungskosten sichtbar zu machen, indem sie Ressourcen für jedes System klar einfordert – und das aus gutem Grund. Wenn niemand das Tool vollständig versteht, um Updates oder administrative Aufgaben durchzuführen, wird aus dem vermeintlich glänzenden neuen Tool schnell ein Problem.

Besonders riskant ist, wenn ein Tool von einem einzelnen „Evangelisten“ eingeführt und betreut wird. Verlassen oder versetzt sich diese Person, bleibt das Team auf einem komplexen System sitzen – ein klares Warnsignal, dass Probleme drohen.

Teamfokus: Einfachheit sorgt dafür, dass die Teams aufeinander abgestimmt sind.

Ein Build- oder Überwachungssystem steht stets im Fokus: Probleme und Updates werden sofort erkannt und behoben. Sobald jedoch mehrere solcher Systeme parallel existieren, neigen Ingenieure und Management dazu, der unbeliebten Fehlerbehebung auszuweichen und stattdessen an der Einführung neuer Funktionen in anderen Tools zu arbeiten. Datenaktualisierungen werden vergessen, unnötige Datenerfassungen verbrauchen Ressourcen, und die Produktivität leidet, wenn der Fokus ständig zwischen Tools wechselt. Besonders bei Überwachungs- oder Wissensmanagement-Tools kann dies zu falschen Entscheidungen führen, da Manager sich auf unvollständige oder falsche Daten verlassen.

Ein zentraler Punkt ist der Tool-Eigentümer. Nicht eine einzelne Person, sondern ein Team muss für Verwaltung, Updates und die korrekte Nutzung verantwortlich sein. Ohne diesen Eigentümer wird das Tool unkontrolliert genutzt, es entstehen unregelmäßige Anwendungsfälle, die Wartung wird schwieriger und das gesamte Team verliert den Überblick.

Ein praktisches Beispiel: Ein Unternehmen war kurz davor, die Speichergrenze seiner Cloud-Repositories zu erreichen, weil ein Team viele Binärdateien hochgeladen hatte. Die Korrektur – das Verschieben der Dateien nach Artifactory – war deutlich aufwendiger und kostspieliger als die Nutzung des Tools selbst.

Wissensaustausch: Gemeinsames Verständnis schlägt individuelles Fachwissen.

Das Wissen darüber, wie ein neues Tool korrekt verwendet und gewartet wird, muss in allen relevanten Teams geteilt und kontinuierlich aktualisiert werden. Dies verursacht entweder direkte Kosten oder zeigt sich indirekt in Verzögerungen – aber es ist unvermeidlich.

Ein Beispiel ist die Einführung einer neuen Programmiersprache: Ein erfahrener Ingenieur kann sich schnell einarbeiten, doch es dauert Monate oder sogar Jahre, bis er sie wirklich beherrscht. In der Zwischenzeit fallen oft zeitaufwändige Refactoring-Aufgaben an, um den neuen Code an bestehende Qualitätsstandards und Best Practices anzupassen.

Ebenso muss sorgfältig geklärt werden, wie ein neues Tool zusammen mit bestehenden Tools eingesetzt wird, um den Datenfluss nachvollziehbar zu halten. Ein typisches Beispiel: Ein Team lud Binärdateien in ein Git-Repository – eine ungeeignete Nutzung. Neue Mitarbeiter mussten mühsam herausfinden, wo die Daten tatsächlich gespeichert waren, und die fehlende Überwachung der Speichergrenzen erschwerte die Arbeit zusätzlich.

Aber die KI wird es schon richten!

Diese Meinung ist zwar bei vielen Unternehmen beliebt, die den Kampf gegen die Komplexität verloren haben, aber sie ist falsch. Wenn man dem Chaos noch KI hinzufügt, fügt man letztlich nur eine weitere Ebene der Komplexität hinzu, über die man noch weniger Kontrolle hat. Wenn eure Komplexität einen Punkt erreicht hat, an dem kein menschliches Team mehr die Chance hat, die Vorgänge zu verstehen, sitzt ihr auf einer tickenden Zeitbombe.

Ich schätze den Einsatz von KI-Tools in meiner täglichen Arbeit sehr und empfehle, sie zu nutzen, um Komplexität in den Griff zu bekommen und sie zu reduzieren, anstatt sie blindlings zu erhöhen.

Wie man fokussiert bleibt

Bevor ein neues Tool in euren Tech-Stack aufgenommen wird, haltet einen Moment inne und fragt euch:

• Brauchen wir es wirklich?
• Wie hoch sind die Gesamtkosten – inklusive Wartung und Lernaufwand?
• Können wir mit den Funktionen eines bestehenden Tools zufriedenstellende Ergebnisse erzielen?
• Welchen echten Nutzen bringt das Tool für das Produkt?

Wendet diese Fragen regelmäßig auch auf die Tools an, die ihr bereits nutzt, und reduziert den Bestand gezielt – so wie Bruce Lee seine Kicks trainierte: Fokus auf das, was im Kampf wirklich wirkt.

Wenn ihr ein neues Tool einführt, startet zunächst mit einem MVP statt POC. Die gewonnenen Erkenntnisse zeigen oft, dass das neue Tool gar nicht notwendig ist.

Hört auf, 9.999 Kicks zu trainieren –und konzentriert euch auf die, die den Unterschied machen.