On Lean and Agility

Zu den grossen Problemen der Softwareentwicklung gehört ihr hoher Abstraktionsgrad, der einfache Erklärungen und Visualisierungen unglaublich schwer macht. Angesichts dessen ist dieser Vortrag von Aubrey Chipman und Roberto Perez Alcolea etwas Besonderes, da in ihm selbst Fachbegriffe wie Direct/Transitive Dependencies und Artifact Observability sichtbar gemacht und lebhaft erklärt werden.

Was mich übrigens ursprünglich in dieses Video hineingezogen hat, ist der direkt am Beginn eingebrachte Spoiler "This is not an AI talk". Nichts gegen künstliche Intelligenz, die revolutioniert gerade die Softwareentwicklung. Aber in letzter Zeit waren mir die meisten Konferenzen zu Hype-getrieben und zu monothematisch. Es gibt genug andere spannende Themen, so wie dieses hier.

 Eines der folgenschwersten Missverständnisse der Softwareentwicklung ist, dass die Rolle des Architekten eine rein technische ist. Ich glaube, dass es sich um eine zutiefst soziale Rolle handelt, eine bei der man sowohl in der Lage sein muss, komplexe Inhalte an Andere zu vermitteln, als auch zu extrahieren, was Andere meinen, wenn sie bestimmte Schlagworte benutzen. Kevlin Henney gelingt hier beides gleichzeitig.

Was er ausserdem dankenswerterweise herausstreicht ist, dass diese Rolle Geduld und Nachsicht erfordert. Sein André Gide-Zitat bringt es auf den Punkt: "Alles wurde bereits gesagt, aber da niemand zuhört müssen wir es ständig wiederholen." Ein Architekt der dazu nicht bereit ist, wird es schwer haben seinen Job gut auszuüben. Im übrigen eine bemerkenswerte Parallele zu allen Methodiker-Berufen.

Ich glaube ja, dass man die Entstehungsgeschichte von Ideen und Praktiken kennen sollte, wenn man wissen will, wie sie gedacht sind, welche Probleme sie lösen sollen und wofür sie nicht gedacht sind. Vor diesem Hintergrund bin ich sehr angetan von diesen Ausführungen von Hana Amiri, die sehr schön darstellt wo DevOps herkommt, wie es sich entwickelt hat, was es erleichtert hat und zu welchen neuen Problemen es geführt hat.

Der Gedanke hinter dem provokanten Titel, der das Paradigma "You build it, you run it" negiert, ist, dass diese doppelte Verantwortung viele Teams übermässig belastet und daher nicht skaliert. Der sich daraus ergebende Schluss, dass Platform Engineering die beste Form von DevOps at Scale ist, dürfte kontroverse Debatten auslösen - genau wie gute Vorträge es sollen.

Witzig ist das auf gleich zwei Ebenen: zum einen, weil es die durch die DevOps-Community wabernden Buzzword-Wolken treffend persifliert, zum anderen weil in dem ganzen Wortsalat einige sehr scharfe Abrechnungen mit häufigen Umsetzungs-Fehlern versteckt sind. "DevOps is a mindset - you build it, you run it. Now you're bad at building and running it." Soll tatsächlich so vorkommen.

Bild: Javier Alvarez / Picryl - Public Domain

In der agilen Softwareentwicklung sollte man sich stets eines Grundsatzes bewusst sein: alle Methoden, Frameworks, Meetings, Rollen, Werte und Prinzipien sind schön und gut, wenn die entstehende Software aber nicht schnell und mit vertretbarem Aufwand anpassbar ist, ist all das nur von bescchränktem Wert. Auch Entwicklungs-Praktiken und Architektur-Muster sind daher von Bedeutung, unter anderem eines, der leider ralativ unbekannt ist: Construct to deconstruct.

Die Grundidee dahinter ist einfach: zum agilen Entwicklen von Software gehört auch, dass vergangene Erweiterungen oder Modifikationen wieder rückgängig gemacht werden, sei es, weil es sich bei ihnen um Übergangslösungen oder MVPs gehandelt hat, oder seit es weil sich herausgestellt hat, dass bei den Anwendern keine Nutzungs- oder Bezahlbereitschaft besteht. In diesen und in anderen Fällen macht ein rückgängig Machen Sinn, um Umfang und Komplexität der Codebase zu reduzieren.

Dort wo das nicht schnell und einfach möglich ist, können verschiedene negative Auswirkungen auftreten - bestenfalls ist die Wiederherstellung eines früheren Zustandes einfach nur aufwändig und beansprucht Zeit und Ressourcen, schlimmstenfalls ist es nicht möglich und eine mit dem früheren Zustand vergleichbare Ersatzlösung muss gebaut werden, was nicht nur aufwändig ist, sondern ggf. auf Kosten von Konsistenz, Updatefähigkeit (bei Standardsoftware) oder Ähnlichem geht.

In der Umsetzung besteht die häufigste und offensichtlichste Form einer Construction for Deconstruction aus einer modularen Architektur der jeweiligen Software. Diese ist gegeben, wenn die Anwendung in selbstständige, voneinander unabhängige Einheiten gegliedert ist, die jeweils eine bestimmte (bestenfalls fachliche) Funktion erfüllen, mit anderen Einheiten nur über fest definierte Schnittstellen verbunden sind und einzeln angepasst werden können, ohne die jeweils anderen auch verändern zu müssen.

Ebenfalls offensichtlich ist, dass der vorherige Zustand bekannt bleiben muss, um wiederhergestellt werden zu können. Das kann ganz banal durch ein Abspeichern eines bestimmten Entwicklungsstandes des Codes stattfinden (und nicht nur der jeweils letzten Versionen), aber auch durch ein Sichern des entsprechenden Standes der dazugehörigen Dokumentation, idealerweise in einer Form, die nicht nur den Zustand beschreibt, sondern auch auch die Entscheidungen die ihm zugrundeliegen.

Etwas weniger offensichtlich aber nicht weniger bedeutsam ist, dass auch der zwischenzeitlich angepasste und jetzt wieder zu entfernende, bzw. auf den früheren Zustand zurückzusetzende Code verständlich und gut dokumentiert ist. Nur wenn sicher ist was er tut und welche Abhängigkeiten von ihm ausgehen kann er entfernt, bzw. zurückgesetzt werden, ohne dass es dabei zu überraschenden Seitenauswirkungen kommt, die wiederum ungeplante Verzögerungen und Aufwände mit sich bringen.

Und natürlich sind auch hier Testabsicherung / Testabdeckung und Monitoring von Bedeutung. Sowohl bei der Validierung ob der "neue alte Zustand" funktionsfähig ist, als auch bei der Sicherstellung, dass die Entfernung des "alten neuen Zustandes" keine unerwarteten Probleme mit sich bringt sind sie für eine schnelle und sichere Umsetzung unverzichtbar (bzw. wenn sie nicht gegeben sind ist mit hohen Aufwänden und verspätet erkannten Überraschungen zu rechnen).

Zuletzt noch eine nicht-technische Anmerkung: dass der Construct to deconstruct-Grundsatz nur verhältnismässig selten befolgt wird hat unter anderem einen sehr menschlichen Grund: es erscheint (bewusst und unterbewusst) naheliegender Veränderungen herbeizuführen, indem man etwas Bestehendem etwas Neues hinzufügt, und weniger naheliegend, dafür etwas Bestehendes zu entfernen. Mehr dazu hier, im Nature-Magazin.

Es kommt nicht mehr oft vor, dass eine neue Art der Software-Programmierung erfunden wird, aber es kommt vor, zuletzt im Februar 2025 durch Andrej Karpathy, einen slowakisch-kanadischen Software-Entwickler und ehemaligen Manager von Tesla und OpenAI. Der neue Programmier-Stil wurde von ihm in einem Posting im Social Nework X zum ersten mal beschrieben und Vibe Coding genannt. In kurzer Zeit erreichte er weitgehende Bekanntheit. Hier ist seine Beschreibung:

Zu Deutsch: Vibe Coding benötigt eine künstliche Intelligenz mit Spracherkennung. In der Interaktion mit dieser gibt man sich ganz seiner gegenwärtigen Stimmung (den Vibes) hin, äussert Wünsche und Vorstellungen und und lässt die KI auf diese Weise fast ausschliesslich durch Spracheingabe ein Stück Software erstellen, das dann irgendwann mehr oder weniger fertig und lauffähig ist. Mit Karpathys eigenen Worten: "just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works".

Aufbauend auf diesen Beitrag kam es in kurzer Zeit zu zahlreichen Artikeln in Medien wie Fortune, Forbes, TechCrunch und New York Times, die grossteils den selben Tenor hatten: Programmieren lernen ist nicht mehr nötig, auch als Laie kann man jetzt Software erstellen. Viele dieser Beiträge waren ausserdem verbunden mit marktschreierischen Verheissungen (jeder kann jetzt ein Startup gründen und reich werden) oder Untergangsszenarien (alle Entwickler werden bald arbeitslos sein).

Dass all das erkennbar an der Realität vorbeigeht hätte man dabei bei einem sorgfältigeren Lesen von Karpathys Post leicht erkennen können. Wie er selbst schreibt und wie kritische Stimmen bald anmerkten führt Vibe Coding dazu, dass selbst der "Urheber" nicht mehr genau sagen kann, wie sein Code entstanden ist und was er im Detail tut. Im besten Fall führt dieser Blindflug zu vielen kleinen Bugs, im schlechtesten Fall zu schweren Fehlfunktionen. Zum Herumspielen ist das gut, zu mehr aber nicht.

In diesem Herumspielen steckt allerdings auch eine Potential, das man nicht verachten sollte: mit Vibe Coding erstellte Anwendungen taugen zwar nicht für echte Markt- oder Produktions-Anwendungen, was sie aber sein können sind erstaunlich realitätsnahe Prototypen, mit denen man in Product Discovery oder Lean Startup Nutzerbedürfnisse und Nutzungsbereitschaft evaluieren kann, um sich dann schnell dem Bedarf anzupassen - frühe Entwicklungsphasen lassen sich so deutlich beschleunigen.

Und was ebenfalls oft nicht ausreichend beachtet wird: das "Programmieren" mit Hilfe gesprochener Prompts führt dazu, dass Anforderungen wesentlich klarer und präziser formuliert werden müssen als das in den meisten klassischen Anforderungs-Dokumenten der Fall ist, die oft eher kryptisch, verschachtelt und inkonsistent sind. Am Ende hat man im Vibe Coding also gleich zwei Ergebnisse - einen vorführbaren Prototyp und klarer formulierte Wünsche und Anforderungen.

Zu den (wenigen) Kritikpunkten an Extreme Programming (XP) gehört, dass es seit ca. dem Jahr 2000 nicht mehr weiterentwickelt wurde. Diese Einschätzung ist allerdings falsch - wie XP-Erfinder Kent Beck in diesem Interview erklärt, gibt es mittlerweile mindestens einen neuen Bestandteil: TCR (mit dieser Abkürzung wurde der etwas sperrige ursprüngliche Name test && commit || revert ersetzt). Verkürzt gesagt: neu geschriebener Code wird in kleinsten Mengen sofort nach dem Schreiben durch einen vordefinierten Test geprüft - und bei fehlgeschlagenem Test automatisch gelöscht, so dass man neu beginnen muss. Extreme Programming, aber noch ein bisschen extremer als bisher.

Das Interview umfasst ausserdem noch verschiedene weitere Themen. Wer ein bisschen Zeit hat und sich auch zu denen informieren will, kann das auf der Website zum Interview tun, wo es nicht nur das Transkript gibt, sondern in ihm eingebettet weitere Videos, die das jeweilige Thema vertiefen.

Es ist wieder soweit - ein Hoch auf die Wissenschaft! Diesesmal auf eines der in Relation zu ihrem Einfluss viel zu unbekannten Research Papers, The Ironies of Automation, verfasst 1983 von der amerikanischen Psychologin Lisanne Bainbridge. Seine Kernaussage: anders als man denken könnte führt Prozessautomatisierung nicht zwangsläufig zu mehr Effektivität oder Effizienz, stattdessen kann es sein (und das ist die Ironie der Geschichte), dass danach alle genauso stark beschäftigt sind wie davor.

Für dieses Phänomen gibt es Gründe. Zum einen führt eine Automatisierung nachvollziehbarerweise dazu, dass der jeweilige Mensch sich weniger mit seinem eigentlichen Arbeitsgegenstand beschäftigt, da diese Aufgabe ja jetzt von einer Maschine oder einem Computer übernommen wird. Sobald ein Eingreifen dann doch nötig wird (und sei es nur um zu überprüfen ob die automatisierte Arbeit richtig ausgeführt wird), dauert das aufgrund der fehlenden Erfahrung länger und ist fehleranfälliger.

Des Weiteren entstehen durch die Automatisierung neue Aufgaben, die es vorher nicht gab. Die Maschine, bzw. die Computerprogramme müssen betrieben, gewartet, repariert und modernisiert werden, was zum einen arbeitsintensiv ist, zum Anderen im Vergleich zu der früher selbst durchgeführten eigentlichen Arbeit deutlich abstrakter und monotoner, was zu nachlassender Konzentration führt, mit der erneuten Folge, dass die Wahrscheinlichkeit von Fehlern (die dann repariert werden müssen) steigt.

Zuletzt entsteht durch die Notwendigkeit, sowohl den eigentlichen Arbeitsgegenstand als auch die Automatisierungstechnik zu beherrschen, eine hohe kognitive Belastung, die auch hier wieder zur Ursache menschlicher Fehler werden kann. Dabei kann es sogar zu einer "Automatisierungs-Ironie in der Automatisierungs-Ironie" kommen, wenn zur Reduzierung dieser Belastungen konzipierte Automatisierungen durch ständige Ergebnisberichte selbst kognitiv belastend werden.

Einen einfachen Ausweg aus diesem Dilemma bietet Lisanne Bainbridge nicht, stattdessen weist sie darauf hin, dass die Lösung nur daraus bestehen kann, ein einzelfallspezifisches Optimum an Automatisierung zu finden, das jeweils bestimmt wird durch Umfang und Komplexität der Prozesse, Änderungs-Häufigkeit, (In-)Stabilität der Umgebung und des Arbeitsgegenstandes, Auswirkungsgrad möglicher Fehler und Qualifikation des jewils eingesetzten Personals.

Auch hier läuft es damit einmal mehr darauf hinaus, sich in einer unbeständigen Welt durch Inspect & Adapt kontinuierlich neu auszurichten und das für den Moment beste Vorgehen zu finden, das sich aber bereits bald wieder ändern kann. Und selbst wenn Lisanne Bainbridges Ironies of Automation sich ursprünglich auf die Frühzeit der Digitalisierung in den 80er Jahren bezogen hat, sind die Parallelen zur heutigen KI-getriebenen Automatisierung offensichtlich.

PS: eine wichtige Differenzierung - die Ironies of Automation sind klar zu unterscheiden von den oberflächlich ähnlichen Rebound-Effekten. Auch die machen die Effektivitäts- oder Effizienzgewinne von Automatisierungen wieder zu Nichte, die dahinterliegenden Mechanismen sind aber komplett andere. Mehr zu den Rebound-Effekten steht hier.

Mir fällt gerade auf, dass ich noch nie etwas zum Thema Site Reliability Engineering (der Schaffung einfach skalierbarer und trotzdem hochzuverlässiger Softwaresysteme) geschrieben habe. Hole ich irgendwann nach, für den Moment nimmt mir Heinrich Hartmann diese Arbeit aber ab, in dem er gut darstellt, wie das bei seiner Firma (Zalando) gemacht wird.

Was mir besonders gut daran gefällt: er streicht deutlich heraus, dass es sich bei Site Reliability Engineering nicht nur um ein rein technisches Thema handelt, sondern um ein technisch-soziales, das ohne Berücksichtigung der Anwender, bzw. ihrer Wünsche und Reaktionen, nicht zu denken ist.

Heute ein etwas abseitiges Thema: COBOL. Es handelt sich dabei um eine Programmiersprache aus den 50er Jahren (!), auf der bis heute (!!) der Grossteil der Kern-Anwendungen in Banken, Versicherungen, der öffentlichen Verwaltung und vielen anderen grossen Organisationen beruht. In Coding mit Dee gibt es dankenswerterweise einen Überblick darüber was COBOL ist, und was man zu seiner Geschichte und Anwendung wissen muss.

Was mir an Dees Ausführungen besonders gefällt ist die neutrale Einordnung, samt aller Vor- und Nachteile. Sie legt Wert darauf, dass nicht die veraltete Programmiersprache selbst das Problem ist, sondern dass es stattdessen Faktoren wie fehlende Dokumentation, die Verrentung der Wissensträger und die "historisch gewachsenen" Systemstrukturen sind, die zu den Schwierigkeiten führen, über die sich bei COBOL häufig beklagt wird (und wegen denen oft behauptet wird, COBOL-Anwendungen nicht agil weiterentwickeln zu können).

Bild: Pixabay / Peter Kaul - Lizenz

Es ist ein Phänomen, das man immer wieder beobachten kann: in irgendeiner Softwareentwicklungs-Organisation tritt eine Verschlechterung der Arbeits-Effektivität und -Effizienz auf, erst nur ein bisschen, dann ein bisschen mehr, dann deutlich mehr, dann viel mehr. Verbesserungsmassnahmen werden ergriffen, aber im besten Fall verlangsamen sie die Entwicklung nur, im schlimmsten Fall bleiben sie wirkungslos. Es wird immer schlimmer. Für dieses Phänomen gibt es einen Namen: den Runaway-Effekt.

Die Gründe für diese Benennung sind offensichtlich. Zum Einen erinnert die zunehmende Beschleunigung der Verschlechterung an einen Läufer oder Motor, der nach dem Start immer mehr Geschwindigkeit aufnimmt, zum Anderen an den Versuch, eine schnellere Person einzufangen. Aufgrund ihrer höheren Geschwindigkeit wird sie immer in der Lage sein, sich durch Weglaufen dem Zugriff zu entziehen. Übertragen: wenn das Problem an einer Stelle gelöst ist, ist es längst woanders aufgetaucht.

Der Grund für diese Entwicklung ist fast immer der gleiche: irgendwann wurde bewusst oder unbewusst entschieden, technische Schulden aufzunehmen, also nichtfunktionale (und für den Nicht-Techniker unsichtbare) Qualitätsaspekte wie Testabdeckung, Clean Code und stringente Architektur wegzulassen, um dadurch mehr Zeit für die Featureentwicklung zu haben. Das Tückische daran - in der unmittelbar anschliessenden Zeit halten sich die Folgen scheinbar in Grenzen.

Im Einzelnen sehen diese Folgen so aus, dass an einigen Stellen etwas mehr manueller Aufwand entsteht (z.B. beim Testen), und dass Code und/oder Architektur nicht sofort verständlich sind, so dass man sich bei einer Weiterentwicklung zuerst "Hineindenken" muss. Im Hintergrund geht der Runaway-Effekt aber bereits los: bei den manuellen Tätigkeiten kommt es zu Flüchtigkeitsfehlern und neuer Code "erbt" seine Architektur und (Un)Verständlichkeit von dem bereits vorhandenen.

Das addiert sich über die Zeit auf, die manuellen Aufwände (und Fehler) werden immer mehr und die Nachvollziehbarkeit von Code und Architektur wird immer geringer. Beides sorgt ausserdem dafür, dass immer mehr Fehlfunktionen versehentlich ins System gelangen, wo sie mit mühsamer Detektivarbeit gesucht werden müssen, wenn ihre Auswirkungen irgendwann auffallen. In Kombination sind das die Gründe für die ständig grösser werdenden Effektivitäts- und Effizienzverluste.

Schlimmstenfalls kommt es sogar dazu, dass IT-Systeme selbst dann ständig zunehmende Probleme generieren wenn gar nicht an ihnen gearbeitet wird. Unter Lastspitzen zusammenbrechende Systeme können ein Grund dafür sein, aber auch vollaufender Speicherplatz, in den unmöglichsten Situationen auftretende Race Conditions oder Fehler, die nur zu bestimmten Zeitpunkten auftreten können, etwa beim Jahreswechsel oder bei der Sommer- und Winterzeitumstellung.

Ein häufiger Versuch, den Runaway-Effekt in Griff zu bekommen sind so genannte Code- oder Feature-Freezes. Beim ersten wird die Anwendung gar nicht mehr weiterentwickelt (z.B. weil stattdessen ein komplett neues System entwickelt wird), beim zweiten darf nicht mehr an funktionalen Erweiterungen gearbeitet werden, damit alle Arbeitskraft in den Abbau der technischen Schulden gehen kann, die für die Entstehung des Effekts gesorgt haben. Oft anzutreffen ist eine Kombination: Feature Freeze für wichtige oder häufig zu ändernde Teile, vorläufiger Code Freeze für den Rest.

Eine entscheidende Frage bei solchen Reparatur- oder Ablöse-Phasen ist, mit welchem Ziel sie durchgeführt werden. Wenn in ihnen das Ausmass der technischen Schulden unter eine Schwelle gedrückt werden  soll, ab der der Runaway-Effekt auftritt, ist das zumindest etwas, besser wäre ihr weitestmöglicher Abbau. Zum anderen ist entscheidend, ob danach ein erneutes Anstauen technischer Schulden zugelassen wird. Wenn ja, ist es nur eine Frage der Zeit, bis alles von vorne losgeht.

Das was Charity Majors in diesem Vortrag als "moderne Softwareentwicklung" bezeichnet, ist das was ich als Agilität bezeichnen würde: kleine Incremente schnell auf Produktion bringen um schnelles Feedback zu bekommen und schnell darauf reagieren zu können. Und genau wie ich scheint sie regelmässig mit der Aussage konfrontiert zu werden, dass das in regulierten Branchen nicht möglich wäre. Um so dankbarer kann man ihr dafür sein, dass sie klarstellt, dass das sehr wohl geht.

Für alle, die keine Geduld haben, sich die ganzen 40 Minuten ihres Videos anzusehen, habe ich eine Empfehlung: ab Minute 14:27 klickt sie sich in einem Schnelldurchlauf von 30 Sekunden durch 13 Folien, auf denen dargestellt wird, wie 13 verschiedene Firmen ihre Entwicklungsprozesse gleichzeitig modern und compliant gehalten haben (es emfiehlt sich, das Video auf jeder Folie kurz zu stoppen). Man sieht daran, dass es geht - man muss es nur wollen und machen.

Wenn die Rede darauf kommt, wie sehr der Einsatz von KI die Softwareentwicklung beschleunigen und verbessern kann, stösst die Vorstellungskraft vieler Menschen an ihre Grenzen. Ryan Salva ist so freundlich und führt live auf der Konferenzbühne der YOW-Konferenz 2023 anhand des GitHub Copilot vor, wie man sich das vorstellen kann. Beeindruckend.

Die spannenden Fragen, die diese Vorführung aufwirft: wenn über Retrieval Augmented Generation Code von anderen Entwicklern bezogen oder dieser auf Basis von Reinforced Learning from Human Feedback automatisiert modifiziert wird, wie kann verhindert werden, dass das Model versehentlich durch schlechten Code kontaminiert wird? Wie sicher sind die hier nur kurz zu sehenden Absicherungen gegen Bugs, Urheberrechtsverletzungen und anstössige Inhalte wirklich? Und wie kann verhindert werden, dass die Einfachheit der Codegenerierung dazu führt, dass im Überschwang der Gefühle so viel erzeugt wird, dass die Codebase unnötig aufgebläht wird? Die Antworten darauf werden wesentlich beeinflussen, ob mit KI wirklich bessere, schnellere Ergebnisse möglich werden, oder ob die Aufwände einfach nur an andere Stellen verlagert werden. Hoffen wir auf das erste.

Das schönste Missverständnis zum Begriff CI habe ich einmal mit einer UX-Designerin erlebt, die der festen Meinung war, die Entwickler in ihrem Team würden über Corporate Identity sprechen. Clare Sudbery dürfte über dieses Level an Verständnis weit, weit hinausgekommen sein. Richtigerweise ist es bei ihr Continuous Integration, oder wie es ihrer Meinung nach heissen müsste "Continuous Trunk Based Development" (CTBD).

Wer CI kennt, wird vor allem nickend vor dem Bildschirm sitzen, einige kleine Erkenntnisse sind aber sicherlich für jeden dabei. Mir war zum Beispiel nicht klar, dass Kent Beck bereits im Rahmen von Extreme Programming CI (noch unter einem anderen Namen) beschrieben hat.

Zu den Folgeerscheinungen der zunehmenden Verlagerung der Verantwortung für agiles Arbeiten zu Menschen ohne technischen Hintergrund (Managern und Coaches) gehört, dass die zentrale Rolle von technischer Exzellenz immer häufiger vernachlässigt wird. Kevlin Henney zeigt in diesem Talk auf, welche negativen Folgen das haben kann. Seine Kernaussage, die man nicht oft genug wiederholen kann: wer glaubt, dass er technische Exzellenz vernachlässigen kann, um schneller Features oder Business Value zu erzeugen, wird weder das eine noch das andere bekommen.

Was im Hinterkopf zu behalten ist: agile Vorgehensweisen sind mittlerweile auch in vielen Bereichen ausserhalb der Softwareentwicklung verbreitet. In solchen Kontexten ist technische Exzellenz entweder etwas Anderes (z.B. in der agilen Hardware-Entwicklung) oder hat ein Äquivalent in einer anderen Art der Umsetzungs-Expertise (z.B. im Event- oder Change Management). Wichtig ist eine wie auch immer geartete Umsetzungs-Exzellenz aber in jedem Fall.

Bild: Unsplash / Paymo - Lizenz

Noch einmal zum Thema Conway's Law, jener von Melvin Conway definierten Gesetzmässigkeit, derzufolge Organisationen dazu tendieren, in ihrer IT-Systemlandschaft ihre Kommunikations- (oder Organisations-)struktur abzubilden. Da das problematisch (weil aus Softwarearchitektur-Sicht dysfunktional) ist, gibt es immer wieder Versuche, dieser Entwicklung gegenzusteuern. Der bekannteste derartige Ansatz trägt den Namen "Inverse Conway Maneuver", oder "Inverse Conway".

Erstmals formuliert 2010 von Jonhy Leroy und Matt Simons beruht Inverse Conway auf der Erkenntnis, dass Conway's Law in der Realität kaum zu vermeiden ist. Statt sich beim Versuch es zu verhindern aufzureiben wird stattdessen versucht es zu nutzen. Indem die Kommunikations- und Organisations-Strukturen bewusst so gestaltet werden, dass diese der gewünschten Software-Architektur entsprechen, wird diese herbeigeführt, bzw. gibt es keine Tendenz mehr, von ihr abzuweichen.

An einem Beispiel erklärt: würde ein Web-Shop von einem grossen Frontend-Team und einem grossen Backend-Team gebaut werden, wären laut Conways Law schwer weiterentwickelbare Frontend- und Backend-Monolithen die Folge. Kleine Teams, die in fachlichen Bereichen (Produkt-Suche, Produkt-Auswahl, Produkt-Bezahlung, etc.) jeweils Frontend und Backend verantworten, würden dagegen zu einer Struktur eigenständiger und vergleichsweise einfach weiterzuentwickelnder Module führen.

Aus Sicht einer agilen Produktentwicklung wäre eine derartige Konstellation grundsätzlich erstrebenswert, da sie die Aufwände für Planung, Abstimmung, Integration und Qualitätssicherung deutlich reduziert, wodurch für die eigentliche Weiterentwicklung mehr Kapazität zur Verfügung steht, die dazu auch noch früher, bzw. schneller genutzt werden kann. Das Ziel einer Liefer- und Reaktionsfähigkeit in kurzen Zyklen wäre damit einfacher erreichbar.

Wie alle scheinbar einfachen Lösungen ist aber auch das Inverse Conway Maneuver mit Vorsicht zu betrachten. In vielen Fällen kann das Ausmass technischer Komplexität in einem fachlich geschnittenen Modul so hoch sein, dass es für sein Team nur noch schwer zu beherrschen ist. Gleichzeitig würde eine dogmatische Befolgung von Inverse Conway die Nutzung der Effizienz- und Konsistenz-Vorteile verhindern, die durch Querschnitssysteme (z.B. gemeinsame Benutzerverwaltung) möglich werden.

Wie immer gilt also: es kommt darauf an. Das Inverse Conway Maneuver kann grossen Mehrwert stiften, wenn es mit Sinn und Verstand an der richtigen Stelle durchgeführt wird. Undifferenziert auf alles ausgerollt kann es zu Problemen führen, die schlimmstenfalls so schwerwiegend sind, dass sie die Vorteile wieder aufwiegen. Eine gute Idee wäre daher zu Beginn eine Umsetzung und Erprobung in nur einem Teil der Organisation, um so zu lernen, ob es auch in den anderen Teilen Sinn macht.

Ganz nebenbei: Mel Conway mag den Begriff Inverse Conway nicht. Das ändert zwar nichts am Konzept, es führt aber dazu, dass man sich bei seiner Einführung nicht zu offensiv auf ihn berufen sollte.

Should we call flying an "inverse gravity manoeuver"? https://t.co/mErFO5gK3d

— Mel Conway (@conways_law) April 7, 2021

Wer dieses Video anklickt und sieht, dass es ganze zwei Stunden lang ist, braucht nicht zu sehr erschrecken. Der eigentliche Vortrag von Carola Lilienthal ist nach ca. einer Stunde vorbei, was danach kommt sind Fragen und Diskussion. Selbst die kann man sich aber gut anhören, wenn man sich dafür interessiert, wie sich die Idee (und die Konsequenzen) der technischen Schulden dem Management erklären lassen.

Was ich gut finde ist, dass gegen Ende explizit darauf eingegangen wird, dass die Erklärung für Manager nicht nur verständlich sondern auch relevant sein soll, was u.a. auch bedeutet, dass man versuchen muss, technische Schulden finanziell quantifizierbar zu machen. Das ist natürlich nicht einfach, im Sinn der Zielgruppenorientierung aber unverzichtbar. Und es gibt auch Ratschläge wie das gemacht werden kann.

Ich sage es immer wieder, ein zentraler Schlüssel zu mehr Agilität ist der Abbau von Abhängigkeiten. Das bezieht sich auf Organisationen und Prozesse, es bezieht sich aber auch auf Software. Michael Nygard zeigt sehr schön auf, warum das so ist und was man dagegen tun kann.

Was man an seinem Vortrag besonders hervorheben kann ist, dass er Zusammenhänge der Softwareentwicklung so erklärt, dass man ihm in weiten Teilen auch ohne Informatik-Expertise folgen kann. Er ist daher gut geeignet um Stakeholdern ausserhalb der IT Problemfelder aufzuzeigen.

Ein häufiges Argument gegen iterativ-incrementelle Softwareentwicklung ist, dass diese bei vielen grossen Anwendungen nicht funktionieren würde. Es gäbe zu viele verschiedene Anforderungen, die aufgrund geschäftlicher Zwänge (z.B. dem Beginn des Saison-Geschäfts oder dem Tag des Inkrafttretens eines Gesetzes) alle gleichzeitig in Betrieb genommen werden müssten und nicht nach und nach. Ein Big Bang-Release wäre daher in diesen Fällen unvermeidlich.

Auf den ersten Blick mag das wie ein valides Argument erscheinen, auf den zweiten gibt es aber trotz dieser Vorgaben eine Möglichkeit zum regelmässigen Fertigstellen, Integrieren und Testen neuer Funktionen. Sie basiert auf dem Konzept so genannter Feature Toggles (alternativ auch Feature Flags genannt), deren Funktion vereinfacht gesagt ist, bestimmte Teile einer Anwendung unsichtbar und unbenutzbar zu machen (welche das sind kann bei der Erstellung bestimmt werden).

Bedingt durch diese Technik ist es möglich, auch solche Funktionen live zu schalten, die für sich genommen oder zu diesem Zeitpunkt noch nicht live sein sollten. Ein typisches Vorgehen ist, das zu einem Zeitpunkt zu tun, an dem normalerweise keine Benutzung stattfindet (z.B. tief in der Nacht), die Akzeptanz-, Regression- und Lasttests einmal laufen zu lassen und die neuen Funktionen dann unsichtbar zu machen (man spricht dabei vom sogenannten "Austogglen").

Auch differenzierte Varianten des Austogglens sind möglich, z.B. das sichtbar-, bzw. unsichtbar machen für verschiedene Gruppen, verschiedene geografische Regionen oder verschiedene Zugangsberechtigungen. Bei Bedarf können so der Betrieb der alten Funktionen und das Testen der neuen Funktionen parallel stattfinden, und bei zeitlich versetzten Livegängen für verschiedene Märkte lässt sich das temporäre gleichzeitige Existieren verschiedener Branches vermeiden.

Selbst nach dem jeweiligen Livegang können Feature Toggles noch einen Zweck haben. Wenn einzelne Teile einer Anwendung einen wesentlichen Teil des Traffics erzeugen, kann es beispielsweise Sinn machen, sie auf diese Weise mit einer "Notfallabschaltung" zu versehen. Im Fall von Lastspitzen kann damit dann ein Crash des Gesamtsystems verhindert werden, stattdessen stehen nur einzelne Features vorrübergehend nicht zur Verfügung.

Um negative Seiten nicht zu verschweigen - sobald sie nicht mehr benutzt werden sollten Feature Toggles wieder entfernt werden, sonst blähen sie den Code unnötig auf und machen ihn schwerer verständlich (und ganz abgesehen davon, kann es bei ihnen zu versehentlicher Aktivierung und Bedienfehlern kommen, wodurch Anwendungen unbrauchbar werden können). Das passiert aber häufig nicht, weil anderes gerade wichtiger erscheint. Fehlender Clean Code ist dann die Folge.

Trotz dieses Risikos: grundsätzlich sind Feature Toggles sehr nützliche Werkzeuge, durch die auch das iterativ-incrementelle Ausliefern grosser Anwendungen möglich wird. Und dank ihnen kann man auch wunderbare Sätze formulieren, wie diesen hier: Wenn das austogglebare Feature eingetoggelt ist, der Feature-Toggle aber ausgetoggelt, dann ist das austoggelbare eingetoggelte Feature nicht mehr austoggelbar. So sieht es nämlich aus.

Bild: Direct Media / StockSnap.io - CC0 1.0

Wenn man versucht Kategorien für verschiedene Arten von Software-Anwendungen zu bilden landet man häufig bei einem bekannten Gegensatzpaar: Individualsoftware, bei der es sich gewissermassen um eine "massgeschneiderte Lösung" handelt und Standardsoftware, die eher "von der Stange gekauft wird". Diese Unterteilung ist auch nicht falsch, zumindest in grösseren Unternehmen lässt sie aber eine wichtige Zwischenkategorie aus und ist dadurch zu ungenau.

Für das bessere Verständnis zunächst ein Blick auf die beiden Grundkategorien, zuerst auf die Individualsoftware. Wie der Name erahnen lässt ist sie jeweils für einen einzigen, meist sehr speziellen Zweck erstellt worden und lässt sich meistens auch nur für den verwenden. Das sorgt auf der einen Seite zwar dafür, genau die nötige Lösung zu haben (wenn es denn richtig gemacht wird), ist aber auf der anderen Seite durch die jeweilige Einzelanfertigung recht teuer.

Standardsoftware dagegen ist für einen häufig und in verschiedenen Unternehmen anzutreffenden Zweck konzipiert, lässt sich also nach einer einmaligen Erstellung immer wieder benutzen und verkaufen (das bekannteste Beispiel dürfte das Computer-Betriebssystem Windows sein). Aus Käufer-Sicht ist neben dem durch Skaleneffekte geringeren Preis der Vorteil, dass der Hersteller für Qualitätsstandards garantiert, Updates entwickelt und einspielt und Schulungsmaterial bereitstellt.

Gerade vor dem Hintergrund, dass praktisch jede Firma heute nur noch auf Basis von Software funktioniert,¹ ist der Markt für Standardsoftware mittlerweile riesig. Von Bürosoftware über Buchhaltungsanwendungen bis hin zu Warenwirtschaftssystemen und den Kernsystemen von Banken und Versicherungen wird überall angestrebt fertige Lösungen zu finden, die man nur noch installieren und benutzen muss, ohne sich mit eigener Entwicklung beschäftigen zu müssen.

Die Realität sieht allerdings anders aus. Implementierungsprojekte von Standardsoftware können heute Jahre dauern, dreistellige Millionenbeträge kosten und ganze Unternehmen an den Rand der Handlungsunfähigkeit bringen (ein Klassiker ist dabei die Einführung von SAP, hier eine Übersicht über die spektakulärsten Fälle). Wie kann das sein, oder anders gefragt: wenn bei dieser Art von Software alles Standard ist, wo kommen die ganzen Aufwände her?

Die Antwort hat mit der zu Beginn genannten Zwischenkategorie zu tun, die keinen allgemein anerkannten Namen hat, die ich aber "Customizing-Software" nennen würde. Es handelt sich dabei um scheinbare (und auch als solche verkaufte) Standardsoftware, die aber ohne umfangreiche Anpassungen an den Anwendungs-Einzelfall (so genanntes Customizing) nicht funktionsfähig ist, was die genannten grossen Einführungsprojekte zur Folge hat.

Die Gründe für diesen Anpassungsbedarf können vielfältig sein, häufig anzutreffen sind aber spezifische, aber vom Standard nicht unterstützte Formatierungen von Produkt-, Finanz-, Prozess- oder Personaldaten im die Software kaufenden Unternehmen, Schnittstellen zu Kunden- oder Lieferantensystemen, die auf bestimmte Art bedient werden müssen, oder bestehende Zentralsysteme (ein schlichtes Beispiel wäre ein Single Sign-On), die bestimmte Rahmenbedingungen vorgeben.

Die sich daraus ergebenden (und in den meisten Fällen nicht vermeidbaren) Anpassungen machen den eigentlichen Vorteil von Standardsoftware, die sofortige Nutzbarkeit des fertig eingekauften Produkts, zu nichte. Nicht nur muss initial ein umfangreiches Customizing stattfinden, auch jedes weitere Update des Herstellers muss durch diesen Prozess, da die ursprüngliche Anwendung durch ihre Modifikation nicht mehr mit den auf dem Standard basierenden Weiterentwicklungen kompatibel ist.

Die mit Customizing-Software verbundenen Einführungs- und Anpassungs-Aufwände sind in sehr vielen Fällen ähnlich teuer wie die Entwicklung einer spezifischen Individualsoftware und in einigen Fällen sogar höher, weshalb man sehr sicher sein sollte, die als Standardsoftware angebotene Anwendung auch weitgehend ohne Customizing nutzen zu können (so wie es z.B. im weiter oben genannten Beispiel Windows der Fall ist). Auf die Angaben der Hersteller sollte man sich dabei nicht zu sehr verlassen.

Die Alternative des in Auftrag Gebens einer eigenen Individualsoftware kollidiert zwar häufig mit den vorhandenen Glaubenssätzen und Vorgaben ("Wir bauen keine Entwicklungsabteilung auf, wir sind doch kein IT-Unternehmen", "Wir müssen immer mehrere Lösungen vergleichen können bevor wir uns für die günstigste entscheiden", etc.), an denen zu arbeiten ist aber auf Dauer deutlich billiger als durch Schmerzen und Kosten herauszufinden, dass es sich bei scheinbarer Standardsoftware meistens doch um Customizing-Software handelt.