Was definiert hochwertige Arbeit in der Softwareentwicklung? Ist es Scrum? Clean Code? TDD? Funktionale Programmierung? In dieser Expert Talks Session präsentieren mein Kollege Milan und ich zwei komplementäre Perspektiven. Milan behandelt die Säulen hochwertiger Engineering-Arbeit, von Teambildung und Kundenzentrierung bis zu Clean Code und Engineering-Kultur. Ich zeige dann, wie DevOps und Continuous Delivery helfen, grossartige Produkte zu bauen, indem man vom Projekt-Mindset zum Produkt-Mindset wechselt.
Es gibt kein Patentrezept#
Die Session beginnt mit einer klaren Botschaft: Es gibt keine einzelne Praxis, die hochwertige Engineering-Arbeit garantiert. Nicht Scrum. Nicht Clean Code. Nicht TDD. Nicht funktionale Programmierung. Stattdessen ist es eine Kombination aus Praktiken, Kultur und Mindset. Und alles beginnt mit dem Team. Man braucht Menschen mit einer Can-Do-Einstellung, die proaktiv sind, lernen wollen und Feedback annehmen können. Gibt man ihnen Sinn und Autonomie, werden sie grossartige Ergebnisse liefern.
Fünf Säulen hochwertiger Engineering-Arbeit#
Milan präsentiert fünf Säulen, die das Fundament für qualitativ hochwertige Engineering-Arbeit bilden:
Kundenzentrierung: Der Kunde will seine Probleme gelöst haben. Er interessiert sich nicht für unsere schicken Architekturen oder Clean Code Frameworks. Wir müssen seine Bedürfnisse jederzeit im Blick behalten.
Gutes Software-Design: Architektur wird überschätzt, aber einfaches Design wird sehr unterschätzt. Mit einem Dokument starten, Design Reviews und Architectural Decision Records einsetzen. Explizit über Trade-offs sein. Für Veränderung designen, mit hoher Separation of Concerns und loser Kopplung.
Gute Code-Qualität: Guter Code ist wie ein Witz: Man muss ihn nicht erklären. Die Boy Scout Rule befolgen, geprägt von Uncle Bob Martin. Jedes Mal, wenn man eine Datei öffnet, eine kleine Verbesserung machen. Eine Variable umbenennen, Logik refactoren, einen fehlenden Test schreiben.
Engineering-Kultur: Eine Kultur schaffen, in der man um Hilfe bitten kann wenn man feststeckt, in der es Zeit für Weiterbildung und Training gibt, in der regelmässig Knowledge-Sharing-Sessions stattfinden, und in der psychologische Sicherheit Experimentieren und Scheitern ermöglicht.
Quality-First-Mindset: Wenn man keine Tests hat, funktioniert es nicht. Die Testpyramide befolgen, 60 bis 90 Prozent Code Coverage anstreben, eine Zero-Bug-Policy anwenden und alles automatisieren, was möglich ist.
“Guter Code ist wie ein Witz. Man muss ihn nicht erklären. Wenn der Code einfach und verständlich ist, braucht man keine Code-Kommentare.”
Technische Schulden bekämpfen#
Technische Schulden kommen in vielen Formen: schlechte Code-Qualität, fehlende Tests, stark gekoppelter Code, ungenutzte Features, veraltete Bibliotheken, schlechtes Tooling, manuelle Prozesse und mangelnder Wissensaustausch. Die Auswirkungen sind real: Im Laufe der Zeit schrumpft die verfügbare Zeit für neue Feature-Entwicklung, während die Zeit, die man mit Komplexität und technischen Schulden kämpft, zunimmt.
Wie kämpft man dagegen an? Erstens: Transparenz schaffen. Technische Schulden für Produkt und Management sichtbar machen. Zweitens: Das Management muss das Team ermächtigen, diese Probleme zu beheben. Im Idealfall entsteht eine Kultur, in der man keine Erlaubnis braucht, um zu refactoren und Dinge zu verbessern. Ja, es mag kurzfristig 10 bis 20 Prozent langsamer machen, aber langfristig gewinnt man alles zurück.
Die Broken-Window-Theorie#
Warum schreiben wir schlechten Code? Die Broken-Window-Theorie erklärt es gut: Wenn man ein Gebäude mit eingeschlagenen Fenstern sieht, fühlt es sich nicht falsch an, noch einen Stein zu werfen. Aber wenn das Gebäude makellos ist, würde man es nicht wagen, es zu beschädigen. Kleine Unordnungen wachsen über die Zeit. Deshalb ist die Boy Scout Rule so wichtig: Die Codebasis jedes Mal sauberer hinterlassen, als man sie vorgefunden hat.
Von Projekten zu Produkten mit DevOps#
Im zweiten Teil der Session erkläre ich eine Herausforderung, die ich in jedem Unternehmen sehe, in dem ich arbeite. Das Business hat grossartige Ideen. Sie schreiben sie in Dokumente und Jira-Tickets und werfen sie über die “Wall of Confusion” zum Entwicklungsteam. Das Entwicklungsteam implementiert etwas und wirft es dem Testing-Team zu. Das Testing-Team wirft es dem Operations-Team zu. Der Kunde sagt: “Was ist das? Das haben wir nicht bestellt.”
Die Ursache liegt in Silo-Organisationen und dem Projekt-Mindset. In einem Projekt sind Scope, Budget und Zeit fixiert, und der Fokus liegt auf der Maximierung des Outputs, der Anzahl gelieferter Features. Aber beim Bauen von Produkten muss der Fokus auf dem Outcome liegen: das echte Kundenbedürfnis verstehen und das echte Problem lösen.
“DevOps ist ein Mindset, eine Kultur und eine Reihe technischer Praktiken, die enge Kommunikation, Integration, Automatisierung und Zusammenarbeit zwischen allen Beteiligten im Wertstrom ermöglicht.”
Die Continuous Delivery Pipeline aufbauen#
Um von Projekten zu Produkten zu gelangen, müssen wir den Wertstrom identifizieren. Value Stream Mapping bringt alle Beteiligten zusammen, um jeden Schritt von der Idee bis zur Produktion zu visualisieren. Es deckt Engpässe auf, indem Lead Time (gesamte verstrichene Zeit) mit Process Time (tatsächlich wertschöpfende Arbeit) verglichen wird. Oft ist der Unterschied erschreckend.
Die Continuous Delivery Pipeline ist das Fliessband der digitalen Fabrik. Sie automatisiert den gesamten Fluss von Code bis Produktion. Das ist im Grunde Platform Engineering: Die Plattform bereitstellen, auf der Teams grossartige Produkte bauen.
Qualität und Betreibbarkeit einbauen#
Qualität muss von Anfang an durch kontinuierliches Feedback eingebaut werden. Das traditionelle V-Modell mit verzögertem Feedback, bei dem Monate zwischen dem Schreiben eines Features und dem Testen vergehen, muss durch einen Shift-Left-Ansatz ersetzt werden. Behavior-Driven Development (BDD) erstellt klare Akzeptanzkriterien, die direkt in Tests umgewandelt werden können. Test-Driven Development (TDD) stellt sicher, dass Tests von Anfang an existieren.
Genauso wichtig ist das Design für Betreibbarkeit. “You build it, you run it” ist nicht nur ein Slogan. Es bedeutet, von Anfang an an Monitoring, Logging, Alerting und Disaster Recovery zu denken. Infrastructure as Code, Application Telemetry und automatisierte Incident Response sind alle essenziell.
Kernaussagen#
Es gibt kein Patentrezept. Hochwertige Engineering-Arbeit erfordert eine Kombination aus grossartigen Teams, Kundenfokus, einfachem Design, sauberem Code und starker Engineering-Kultur.
Technische Schulden sind eine echte Bedrohung. Sichtbar machen, Teams ermächtigen sie zu beheben, und die Boy Scout Rule befolgen: Code sauberer hinterlassen, als man ihn vorgefunden hat.
Von Projekten zu Produkten wechseln. Auf Outcomes fokussieren (echte Kundenprobleme lösen) statt auf Outputs (eine fixe Anzahl Features liefern).
Den Wertstrom identifizieren und optimieren. Value Stream Mapping deckt Engpässe auf. Die Continuous Delivery Pipeline ist das Fliessband der digitalen Fabrik.
Qualität von Anfang an einbauen. BDD und TDD nutzen, um das Testen nach links zu verschieben. Vom ersten Tag an für Betreibbarkeit designen.
Alles automatisieren. Von Builds über Tests über Deployments bis zu Monitoring. Manuelle Prozesse sind der Feind von Geschwindigkeit und Qualität.