Software besitzt eine extrem seltsame Eigenschaft: Es ist möglich, hochwertige Softwareprodukte mit einem faktisch bei Null liegenden Kapitalaufwand zu erzeugen. Sam Penrose, Entwickler bei Mozilla, beschrieb die Softwareprogrammierung als eine Arbeit, die Kapital erschafft.
Diese Eigenschaft unterscheidet Software radikal von technischen Materialien wie Stahl und rückt sie in die Nähe von künstlerischen Medien wie beispielsweise Farben.1 Demzufolge sind Ingenieur oder Softwaretechniker etwas unpassende Begriffe. Es ist ziemlich weit hergeholt, sich Software auch nur als eine Art technisches „Material“ vorzustellen. Auch wenn jede Datenverarbeitung ein physisches Substrat erfordert, scheinen die unzähligen winzigen elektrischen Ladungen innerhalb von Computerschaltkreisen, die physische Verkörperung eines laufenden Programms, kaum materiell zu sein.
Der nächste Verwandte dieses eigenartigen neuen Mediums ist das Papier. Doch selbst Papier ist nicht so billig und so vergänglich. Auch wenn wir den Geist der kreativen Fülle schätzen können, der Poeten des Industriezeitalters dazu brachte, zusammengeknüllte Fehlversuche in Papierkörbe zu werfen, nimmt ein Teil von uns die Verschwendung wahr. Papier könnte beinahe als das ideale Medium für wahrhaftige kreative Fülle gelten, aber eben nur beinahe.
Software hingegen ist ein Medium, dem man nicht nur mit einer Mentalität des Überflusses begegnen kann, sondern sogar begegnen muss. Gute Software kann nur durch ein solches Übermass an Versuch und Irrtum und augenscheinlichem Abfall entstehen, dass es sowohl für traditionelle, ingenieurhafte Produktion als auch für Künstler den Bankrott bedeuten würde. Von den ersten Tagen der interaktiven Computer, als Programmierer sich für das Entwickeln von Spielen entschieden, auch wenn „ernsthaftere“ Probleme auf Rechnerzeit warteten, bis hin zu den modernen Klagen über „unbedeutende“ Apps (die sich im Nachhinein häufig als bahnbrechend erweisen) haben auf Knappheit fokussierte Denker seit fünfzig Jahren nicht gelernt, das grundlegende Wesen der Software zu begreifen.
Für dieses Unvermögen gibt es einen einfachen Grund: Unbefleckte puristische Visionen vermitteln einen Wert, der weit über die Linderung von Ängsten und geordnete Planung hinausgeht. Sie sind nämlich gleichzeitig ein bedeutendes autoritäres Marketing- und Ankündigungsinstrument – so wie ein Galadiner mit teurem Porzellan. Die Vision soll in Bereichen wie der Architektur knappe Ressourcen anziehen und bündeln. In einer Umgebung hingegen, die vom Überfluss geprägt ist, ist der Bedarf an solchen Visionen deutlich geringer. Benötigt wird lediglich eine halbwegs stimmige Entwicklungsrichtung, um mit allen Werkzeugen und Ideen, die zur Verfügung stehen, Kapital zu erzeugen – so wie Gäste einer Selbstversorgerparty, die irgendwie all das herbeiimprovisieren, was für ein gutes Essen benötigt wird.
Wenn man die Analogie zu Essen und Geschirr auf technische Begriffe überträgt, gelangt man in das Herz der Softwareentwicklung. Puristische Visionen entstehen häufig dann, wenn autoritäre Architekten versuchen, knappe Ressourcen zu bündeln und optimal zu nutzen – auf eine Art und Weise, von der sie oft aufrichtig glauben, dass sie für alle das Beste sein wird. Tüfteleien hingegen konzentrieren sich eher auf einen kontinuierlichen Fortschritt als auf optimale Endzustände, die eine allumfassende Vision realisieren. Sie werden meistens von persönlichen Interessen vorangetrieben und befassen sich nicht wie besessen mit grossen und paternalistischen Zielen, die „das Beste für alle“ erreichen sollen. Aus diesem Grund erscheinen puristische Visionen von aussen betrachtet tröstlicher und ästhetisch ansprechender als das pragmatische Hacking, das chaotisch und unkoordiniert erscheint. Gleichzeitig sind puristische Visionen deutlich weniger offen für neue Möglichkeiten und Basteleien, während das pragmatische Hacking für beides extrem empfänglich ist.
In der Computer-Welt wurde die Wichtigkeit von überflussorientierten Ansätzen schon in den 1960er Jahren formuliert. Als das Mooresche Gesetz noch jung war, schrieb der Computerpionier Alan Kay, Programmierer sollten „Transistoren verschwenden“, um die wahre Kraft der Programmierung zu entfesseln.
Doch auch für junge Programmierer, die heute mit ihrer Tätigkeit beginnen und daran gewöhnt sind, Containerladungen von Cloud-Computern minutenweise zu mieten,<sup“>2 bleibt es schwierig, diesem Prinzip zu folgen. Es erscheint als „falsch“, Fähigkeiten und Ressourcen spielerischen Tüfteleien zu widmen, wenn gleichzeitig offensichtliche und ernsthafte Probleme bestehen, die verzweifelt darauf warten, dass sich jemand mit den nötigen Fähigkeiten ihrer annimmt. Wie der Protagonist des Films Zum Teufel mit den Kohlen, dem es schwerfällt, 30 Millionen Dollar auszugeben, um im Gegenzug 300 Millionen Dollar zu erben, müssen auch Softwareentwickler aus der Knappheit geborene Gewohnheiten wieder verlernen, bevor sie in ihrem Medium produktiv werden können.
Das Prinzip, bei ungefährem Konsens den Code einfach laufen zu lassen, ist möglicherweise das zentrale Element der Überflussmentalität im Softwarebereich.
Wer an die Kooperationsprozesse autoritärer Organisationen gewöhnt ist, denkt bei dem Prinzip eines ungefähren Konsenses möglicherweise an eine eher informelle Ausschusssitzung, doch die Ähnlichkeit ist nur oberflächlich. Der Konsens wird in traditionellen Organisationen häufig von nach Harmonie strebenden Einzelpersonen ausgehandelt, die sich auf die Bedürfnisse anderer einstellen, sensibel auf Einschränkungen reagieren und gut darin sind, eine „Angleichung“ zwischen konkurrierenden Autokraten zu erreichen. Dies ist eine natürliche Arbeitsweise, wenn ein Konsens gesucht wird, um mit Knappheit umzugehen. Der typische Zweck einer solchen Konsenssuche des Industriezeitalters ist das Zuweisen limitierter Ressourcen. Unter solchen Bedingungen steht Kompromissbereitschaft für einen Geist des Teilens und der Höflichkeit. Leider ist sie auch ein sicheres Rezept für den Stillstand, wenn es schwierig ist, einen Kompromiss zu erzielen, und kreative Durchbrüche notwendig werden.
Die Softwareentwicklung hingegen bevorzugt Personen mit einer autokratischen Ader, die von einer entschiedenen Vorstellung dessen getrieben werden, was und wie designt werden soll. Auf den ersten Blick scheint dies dem Konsensgedanken zu widersprechen.
Paradoxerweise bedeutet die IETF-Philosophie, auf „Könige, Präsidenten und Abstimmungen“ zu verzichten, dass der ungefähre Konsens durch willensstarke Persönlichkeiten geschaffen wird, die entweder zu einer wahrhaftigen Einigung gelangen oder getrennte Wege gehen, um jeweils ihre eigenen abweichenden Meinungen zu verfolgen. Konflikte werden nicht durch Kompromisse gelöst, die alle Beteiligten unglücklich zurücklassen. Stattdessen werden sie nach dem Prinzip gelöst, das Futurist Bob Sutton als enorm wichtig für den Umgang mit Unsicherheit erkannte: strong views, weakly held – starke Positionen, schwach verteidigt.
Pragmatiker vertreten im Gegensatz zu den autoritären hochmodernistischen Architekten, die James Scott studierte, sehr entschiedene Ansichten, die sich darauf gründen, dass sie laufenden Code anstelle von abstrakten Visionen beigetragen haben. Doch gleichzeitig erkennen sie auch andere als eigenständige Kollegen an, anstatt sie als bedingungslos Untergebene oder als Rivalen zu betrachten. Wenn Konflikte auftreten, sind sie bereit, hart zu arbeiten, um andere zu überzeugen, selbst überzeugt zu werden oder das Projekt zu verlassen.
Der ungefähre Konsens bevorzugt Menschen, die in traditionellen Unternehmen als dickköpfige Störenfriede gelten würden – genau diese sind es, die mit besonders hoher Wahrscheinlichkeit in den „Breaking Smart“-Modus gelangen. In seiner stärksten Form macht der ungefähre Konsens es möglich, die fruchtbarste Entwicklungsrichtung zu finden, anstatt Beschränkungen aufzudecken. Im Bereich der Software sind Beschränkungen meist nur geringfügig und sehr offensichtlich. Die Möglichkeiten hingegen sind beängstigend gross und vielfältig. Die grössten Herausforderungen bestehen darin, limitierenden Visionen zu widerstehen, die fruchtbarste und produktivste Richtung zu finden und sich mit den richtigen Personen zu verbünden.
In einem Prozess, der an die „Regel der Übereinkunft“ des Improvisationstheaters erinnert, werden meist die Ideen, die die meisten Folgeentwicklungen auslösen, als am produktivsten identifiziert und als Konsens angenommen. Die Mitarbeiter, die den stärksten kreativen Flow entfachen, werden als die richtigen wahrgenommen. Der Konsens ist ungefähr, weil er nur eine Richtungsweisung darstellt und nicht als detaillierte puristische Vision ausgearbeitet wird.
Dieses allgemeine Prinzip der Suche nach fruchtbaren Ansätzen wurde schon ziemlich häufig entdeckt beziehungsweise wiederentdeckt und mit einer verwirrenden Begriffsvielfalt belegt. Da gibt es Bezeichnungen wie principle of least commitment (Planungsssoftware), the end-to-end principle (Netzwerkdesign), the procrastination principle (Architektur), optionality (Investitionen), paving the cowpaths (Schnittstellendesign), lazy evaluation (Sprachdesign) oder late binding (Codeausführung). Auch wenn sich diese unterschiedlichen Begriffe en detail in ihren Annahmen und Anwendungsbereichen unterscheiden, laufen sie alle en gros darauf hinaus, die Zukunft so frei und unbeschränkt wie möglich zu halten, indem innerhalb der gegebenen lokalen Rahmenbedingungen so wenige Grenzen wie möglich ziehen.
Dieses Prinzip ist im Grunde Ausdruck einer laissez-faire-Ethik der Programmierung. Donald Knuth, ein weiterer Software-Pionier, griff die ethische Dimension mit seiner eigenen Formulierung auf: Premature optimization is the root of all evil – die vorzeitige Optimierung ist die Wurzel allen Übels. Dieses Prinzip ist der eigentliche Grund dafür, dass Autonomie und Kreativität auf konkrete Entscheidungsprozesse übergehen können. Wenn mehr Entscheidungen der Zukunft überlassen werden, wird auch die Autorität an diejenigen übertragen, die zu einem späteren Zeitpunkt zuständig sein werden.
Solche Prinzipien können gefährlich verspielt und kurzsichtig erscheinen, doch in einer Zeit von wachsendem Überfluss und sinkenden Kosten von Fehlschlägen erweisen sie sich als weise. Im Allgemeinen ist es klüger, anzunehmen, dass Probleme, die heutzutage als schwer lösbar und von hoher Wichtigkeit erscheinen, in Zukunft unbedeutend oder irrelevant werden. Vorgehensweisen, die im Kontext der Knappheit kurzsichtig waren, werden im Kontext des Überflusses weitsichtig und vorausschauend.
So reflektierte beispielsweise das ursprüngliche Design des Mosaic-Browsers die optimistische Annahme, dass zukünftig jedermann über eine Internetverbindung mit hoher Bandbreite verfügt – eine Annahme, die zu jener Zeit nicht der Realität entsprach, aber heutzutage in den Industrienationen grösstenteils zutrifft. Heute entwickeln zahlreiche Fintech-Unternehmen ihre Produkte auf Grundlage der Annahme, dass Kryptowährungen zukünftig allgemein akzeptiert und weithin angenommen werden. Diesem Optimismus gegenüber der Technik liegt ein allgemeiner Optimismus gegenüber der Menschheit zugrunde: der Glaube, dass unsere Nachfahren über weiterreichende Kenntnisse und grössere Fähigkeiten verfügen werden als wir selbst – und somit in der Lage sein werden, kreativere Entscheidungen zu treffen.
Dieser optimistische Ansatz birgt radikale Konsequenzen. Traditionelle Prozesse der Konsenssuche streben Klarheit in langfristigen Visionen an, aber bleiben meistens verschwommen, was die unmittelbar nächsten Schritte betrifft. Der ungefähre Konsens im Softwarebereich hingegen strebt die Unklarheit langfristiger Ergebnisse bewusst an und zielt gleichzeitig auf eine extreme Klarheit der unmittelbar folgenden Schritte ab. Letzteres wirkt der Tendenz entgegen, die kurzfristigen Möglichkeiten zu überschätzen, während ersteres, das Akzeptieren unklarer Visionen, dem Unterschätzen dessen, was langfristig möglich sein wird, entgegenwirkt. Auf ethischer Ebene ist der ungefähre Konsens zutiefst antiautoritär, denn er verzichtet darauf, die Freiheit zukünftiger Akteure zu beschränken, nur um aktuelle Bedenken zu zerstreuen. Die Ablehnung von „Abstimmungen“ im IETF-Modell ist keine Ablehnung demokratischer Prinzipien, sondern die Ablehnung eines falschen Gefühls des Egalitarismus.
In anderen Worten: Der richtige Weg ist im Softwarebereich oft derjenige, der Unklarheit und Fruchtbarkeit auf die verlockendste Weise kombiniert – die Richtung der maximalen Interessanz.3
Im Jahrzehnt nach dem Platzen der Dotcom-Blase im Jahr 2000 wurde die Bedeutung dieses Prinzips besonders deutlich. Startups, für die das Nutzerwachstum (eine Richtung der „Interessanz“) erste Priorität hatte, schnitten besser ab als jene, die auf möglichst der stabilen Rentabilität (die selbstbegrenzende puristische Vision eines idealisierten Unternehmens) aus waren. Die Super-Unternehmen der Interessanz wie Google und Facebook erwiesen sich als hochprofitabel. Unternehmen, die ihre Geschäftsmodelle vorzeitig optimierten, um der Angst vor unzureichenden Umsätzen zu begegnen, begrenzten ihr eigenes Potential und würgten ihr eigenes Wachstum ab.
Der grosse praktische Vorteil dieser Entscheidungsregel besteht darin, dass die Richtung der maximalen Interessanz sehr schnell angepasst werden kann, um neue Informationen zu berücksichtigen, indem der ungefähre Konsens weiterentwickelt wird. Für derartige Neuorientierungen gewann kürzlich der Begriff pivot – wörtlich: der Dreh- und Angelpunkt – an Popularität, der von Eric Ries im Rahmen des Lean Startup-Konzepts geprägt wurde. An einem solchen Wendepunkt kann sich die Richtung der Entwicklung schlagartig ändern, ohne dass ein detaillierter langfristiger Plan besteht. Es reicht aus, die nächsten experimentellen Schritte auszumachen. Diese Fähigkeit, sich neu zu orientieren und schnell neue mentale Modelle anzunehmen (von Militärstrategen als fast transient bezeichnet4), bildet das Herzstück der Agilität.
In autoritären Entwicklungsmodellen ist die Reaktion auf neue Informationen genau entgegengesetzt. Diese Modelle basieren auf detailgenauen puristischen Visionen, die mit der Zeit komplexer werden, sodass es immer schwieriger wird, neue Daten miteinzubeziehen. Dementsprechend besteht die typische Reaktion auf neue Informationen darin, sie als irrelevante Störung zu bezeichnen, die Verpflichtung gegenüber der ursprünglichen Version zu bekräftigen und wie bisher weiterzumachen. Hier sind wir wieder beim Trainwreck-Szenario angelangt. Wenn andererseits neue Informationen den ideologischen Widerstand innerhalb eines demokratischen Prozesses stärken, kann eine konkurrierende puristische Vision entstehen. Dies führt zum Stalled-Train-Szenario.
Der ungefähre Konsens vermeidet beide Resultate, da es deutlich einfacher ist, sich grob auf die interessanteste Richtung zu einigen, als entweder ein komplexes und detailliertes Konzept zu ändern oder zwei oder mehr konkurrierende komplexe Konzepte in Einklang zu bringen.
Damit dies funktioniert, ist eine gleichermassen pragmatische Philosophie für die Umsetzung erforderlich – eine Philosophie, die sich stark von den autoritären hochmodernistischen Methoden unterscheidet oder, wie es in der Softwaretechnik heisst, dem Wasserfallmodell (benannt nach der Art und Weise, auf die puristische Pläne auf hoher Ebene in Richtung der Umsetzungsarbeit auf niedriger Ebene fliessen).
Eine solche pragmatische Philosophie der Umsetzung existiert nicht nur, sondern sie ist sogar so erfolgreich, dass running code selbst den ungehemmtesten Prozess des ungefähren Konsenses überholen kann, ohne zu zerschellen. Diese Dynamik zeigt sich beispielsweise darin, dass erfolgreiche Software meist auf Arten und Weisen verwendet und erweitert wird, die von den ursprünglichen Entwicklern niemals vorgesehen waren; oft werden diese davon positiv überrascht und manchmal auch beunruhigt. Wir sprechen natürlich von dem hier schon mehrfach genannten agilen Modell. Wir möchten uns nicht in technischen Einzelheiten verlieren,5 worauf es ankommt, sind die Konsequenzen seiner Anwendung.
Die grösste Konsequenz: Im Wasserfallmodell bleibt die Ausführung üblicherweise hinter der Vision zurück, was zu einem von Defiziten angetriebenen Prozess führt. Bei der Arbeit mit agilen Prozessen hingegen rast der laufende Code voran und muss von der Vision erst eingeholt werden, sodass ein überschussgetriebener Prozess entsteht.
In beiden Methoden lauert ein Unbekanntes, doch sein Wesen ist sehr unterschiedlich. Der Überschuss, der durch agile Prozesse entsteht, ist der Ursprung von zahllosen angenehmen Überraschungen: Serendipität. Das Defizit im Falle der Wasserfallmodelle ist die Quelle dessen, was William Boyd als Zemblanität bezeichnete: “unpleasant unsurprises” – „unangenehme Nichtüberraschungen“.
Wasserfallprozesse scheitern im Softwarebereich auf vorhersehbare Weise, ganz so wie klassische griechische Tragödien. Agile Prozesse hingegen können zu einer lawinenartigen Serendipität führen und auf ungeahnte Weise immer mehr Erfolge bringen. Der Grund dafür ist einfach: Wasserfallpläne schränken die Freiheit zukünftiger Beteiligter ein und bringen sie dazu, sich unwohl zu fühlen und auf vorhersehbare Weise gegen den grossen Plan aufzubegehren. Agile Modelle hingegen bestärken zukünftige Projektteilnehmer und machen den Weg für Kreativität und unvorhersehbare neue Werte frei.
Der technische Begriff für die von glücklichen Zufällen geprägte, stärkende Diskrepanz zwischen laufendem Code und herrschender Vision ist nun in Form einer häufig missverstandenen Idee in der Popkultur angelangt: perpetual beta.
[1] Siehe hierzu das Essay von Paul Graham, Hackers and Painters.
[2] Moderne Cloud-Computing-Rechenzentren nutzen häufig modulare Architekturen mit Serverracks, die im Inneren von Schiffscontainern installiert sind. Auf diese Weise können sie einfach transportiert, ausgetauscht oder hinzugefügt werden.
[3] Die Wichtigkeit der „Interessanz“ von Arbeit geht weit über Softwareprozesse hinaus. Edmund Phelps (siehe Fussnote 2 in Auf dem Weg in die Massenblütezeit) stellte auf Grundlage von Daten der World Values Survey fest: „How the survey respondents in a country valued the ‘interestingness of a job’ (c020 in the WVS classification) was significantly related to how well the country scored in several dimensions economic performance“, d. h., die von den Umfrageteilnehmern wahrgenommene Interessanz einer Tätigkeit korrelierte stark damit, wie gut das Land in verschiedenen Dimensionen der wirtschaftlichen Leistung abschnitt.
[4] Fast transient ist ein Kunstbegriff in der als Maneuver Warfare bzw. Bewegungskrieg bekannten Militärdoktrin. Der Bewegungskrieg entstand aus einer langen Tradition, die auf Art of War von Sun Tzu und das deutsche Modell des Blitzkriegs im Zweiten Weltkrieg zurückgeht. In seiner zeitgenössischen Form wurde es von Col. John Boyd der US Air Force entwickelt. Die Lean Startup-Bewegung ist in vielerlei Hinsicht eine vereinfachte Version eines Kernkonzepts des Boydschen Bewegungskriegs: der OODA-Loop (Observe, Orient, Decide, Act – beobachten, orientieren, entscheiden und handeln). Der Lean Startup-Begriff des pivot entspricht annähernd dem Gedanken der zügigen Neuorientierung durch einen schnellen Übergang. Eine gute Diskussion der Anwendung von Begriffen des Bewegungskriegs auf Geschäftsumgebungen findet sich in dem hervorragenden Buch Certain to Win von Chet Richards.
[5] Technologen, die gerne agile Methoden erlernen möchten, steht eine Vielzahl an exzellenten Büchern zur Verfügung, beispielsweise The Principles of Product Development Flow: Second Generation Lean Product Development von Donald G. Reinertsen sowie aktive Gemeinschaften von Anwendern, die den Stand der Technik ständig weiterentwickeln.