Warum ist Software-Entwicklung so unfassbar komplex geworden?

Softwareentwickler und Zirkusclowns haben etwas gemeinsam: die Schwierigkeit ihres Berufes wird unterschätzt. „Wie schwer kann das sein?“, ist einer der häufigsten Sätze, den sich IT-Verantwortliche anhören müssen. Es kann doch bitte nicht so schwer sein, diese Oberfläche noch um einen weiteren Knopf zu ergänzen. Oder zu verhindern, dass sich das Programm ständig aufhängt. Oder, im Fall des Schulministeriums Nordrhein-Westfalen, eine simple ZIP-Datei an knapp tausenden Schulen zu schicken.

Aber offensichtlich ist es genau das: sehr schwer. „Selbst Downloads zu schwer für die deutsche Verwaltung" kommentierte golem.de1, als die Abitur-Prüfungen in NRW in der letzte Woche verschoben werden musste. Die anschließende Pressemittteilung des Schulministerium las sich, als „handle es sich um einen hochanspruchsvollen Vorgang in einer Fabrikanlage"2. Ein Tonfall, der vielen bekannt vorkommt, die bei der EDV-Abteilung ihres Unternehmens zum wiederholten Male um eine scheinbare Kleinigkeit bitten. Diese Kleinigkeit kostet die Kollegen in der IT Monate, manchmal Jahre. Während dessen geschieht mit der Software etwas sehr seltsam: sie wird schlechter. Wie ein Bürostuhl, der verschleißt.

Neu ist das alles nicht. In den 60ern sprach die IT-Branche das erste Mal über eine „Software-Krise“: Software wurde immer leistungsfähiger, aber gleichzeitig beschwerten sich Kunden darüber, dass sie immer fehleranfälliger und teurer wurde. Wenn sie denn überhaupt bei den Kunden ankam – es war die Zeit, in der die ersten großen Softwareprojekte scheiterten.

All diese Probleme bestehen bis heute. Die Softwarekrise gilt als nicht beendet. Woran liegt’s? Spoiler: Es liegt nicht in der Technik.

Software ist der Spiegel einer Firma

Die effektivsten Softwareprojekte sind die, an denen genau ein Mensch arbeitet. Diese Person ist deswegen so schnell, weil sie anderen nie erklären muss, was sie sich gerade denkt. Aber in dem Moment, in dem sich eine Gruppe von Menschen zusammentut, steigen die Kosten für die Kommunikation. Der Informatiker Melvin Conway erkannte in den 60ern, dass diese Kosten besonders groß werden, wenn man mit Menschen außerhalb des eigenen Teams (oder der eigenen Abteilung) sprechen muss. Je weniger die Teams miteinander zu tun haben, desto schlechter für die Zusammenarbeit. Daraus leitete er ein Phänomen ab, das heute als Conway’s Law bekant ist: Jede Organisation kann nur Produkte herausbringen, die ein Spiegelbild ihrer selbst sind.

Das klingt sehr theoretisch, aber wir sehen die Auswirkungen dieses Gesetzes ständig in der Praxis. Conways Law erklärt, warum Spotify einen einzigen Player für Songs, Podcast und Hörbücher hat, obwohl das offensichtliche Nachteile hat (Antwort: 1 zentrales Team3). Und es erklärt, warum Windows fünf Lautsprecherregler hat, die alle das Gleiche tun (Antwort: 5 Teams4).

Shuffle-Mode bei Hörbüchern, aber dafür keine Abspielgeschwindigkeit. Komisch, oder?

Wenn also eine Organisation aus einer Unzahl fragmentierter Abteilungen mit unklaren Zuständigkeiten und schlechter Zusammenarbeit besteht, dann wird man das der Software ansehen. Es steht, buchstäblich, im Code. Und genau das ist der Grund, warum sich der Staat besonders schwer damit tut, gute Software zu bauen. Es liegt nicht an den Menschen, die dort arbeiten, sondern daran, wie sie zusammenarbeiten.

Das Schulministerium in Düsseldorf und eine IT-Bude in Arnsberg sind Teil eines Systems, das niemals gute Software produzieren wird.

Software ist Zeitreise

Conway formulierte seine These in einer Zeite, als die Softwarebranche noch sehr neu wahr. Er konnte nur ahnen, was passierte, wenn Programme mehrere Jahrzehnte in Betrieb sind. Solche Programme haben nicht nur die aktuelle Organisationsstruktur in ihrem Code verewigt, sondern alle Strukturen, die die Organisation jemals hatte. Wollen Entwickler etwas an ihnen verändern, kommt das oft einer Mischung aus Zeitreise und Politthriller gleich. Warum arbeitet dieser Komponente mit jener Komponenten zusammen? Und zwar nur an dieser Stelle, nicht an den anderen? Antwort: Weil das zu jener Zeit den Strukturen der Firma entsprach.

Das ist der eigentliche Grund, warum der zusätzliche Knopf im Interface zum Großprojekt wird. Die zuständigen Programmierer können jetzt nicht mehr zum zuständigen Team gehen und fragen: „Warum habt ihr den ersten Knopf damals auf diese Art programmiert?“ Denn das Team existiert nicht mehr. Die Programmierer müssen Kollegen finden, die mal Teil eines Teams waren, das vor Jahren diesen Knopf programmiert hat.

Ein übertrieben abgedrehtes Szenario? Nein. Alltag für Softwareentwickler.

Alles wird einfacher – also komplizierter

Es existiert eine gängige Taktik, um großen, komplexen Problemen Herr zu werden: man schneidet sie in kleine Unterprobleme. Die Softwarebranche hat dazu eine Flut von Werkzeugen erdacht (Container, virtuelle Maschinen, Bibliotheken usw.), die alle die Arbeit von Entwicklern erleichtern sollen. Und das meist auch tun.

Gleichzeitig haben diese Werkzeuge alles noch viel komplexer gemacht. Sie führen dazu, dass man teilweise noch viel länger braucht, um zu verstehen, was da eigentlich im Code steht. Und es wird für Einzelpersonen noch viel schwieriger, „mal eben“ eine kleine Software zu schreiben. Sie müssen immer das große Rad schwingen und sich mit einer Fülle von Werkzeugen und Frameworks auseinandersetzen, bevor sie überhaupt anfangen können.

Ich selbst stoße immer wieder vor dieses Problem: Es gibt ein Dutzend Dinge, für die ich mir am liebsten kurz eine App programmieren würde. Doch der Aufwand, die Maschinerie überhaupt zu starten, übersteigt den Nutzen.

Lösungen

Große Softwareprojekte, an denen viele Menschen arbeiten, haben zur Softwarekrise geführt. Das wird so lange so bleiben, wie wir unsere Gehirne nicht verdrahtet haben oder eine allwissende KI unsere berufliche Kommunikation überflüssig gemacht hat. Also: noch sehr lange.

Wir bräuchten mehr Softwareprogramme, die nur von einem einzigen Team verantwortet werden oder besser noch: von nur einem einzigen Menschen. Wenn Einzelpersonen „mal eben“ Software bauen könnten, die ihr bestimmtes Problem löst, wären wir nicht nur effizienter – die Welt wäre reicher an verrückten Ideen, die mit den aktuellen Strukturen schon beim ersten Schritt stecken bleiben.

Zwei Trends zahlen auf dieses Szenario ein.

  1. „No-Code“-Lösungen ermöglichen es Nicht-Programmierern, Software zu bauen, indem sie einfach vorgefertige Funktionen „zusammenstecken“ – meist in visuellen Editoren. Über Dienste wie Zapier haben manche Menschen große Teile ihrer alltäglichen Aufgaben automatisiert (ich gehöre dazu). Aber auch Teams in Unternehmen haben Software gebaut, ohne auf die IT-Abteilung zu warten. Manche Firmen starten sogar komplett mit No-Code-Produkten.
  2. Generative KI-Tools. GPT & Co. sind schon jetzt sehr gut darin, einfache Aufgaben in Software-Code zu gießen. Sie könnten No-Code-Anwendungen eines Tages vielleicht sogar ersetzen.

Auch wenn manche anderes behaupten: weder No-Code noch KI werden uns von großen Softwareprojekten befreien. Aber sie könnten dazu führen, dass wir weniger solcher Projekte brauchen. Und gleichzeitig mehr davon bekommen, was uns Software eigentlich bringen soll: Lösung von Problemen.


  1. Quelle: Selbst Downloads sind zu schwer für die deutsche Verwaltung ↩︎

  2. Quelle: 600.000 Liter giftiges Downloadwasser verseuchen Rhein bei Düsseldorf (Markus Reuter, 2023) ↩︎

  3. Die Arbeitsweise von Spotify (das „Squad-Modell“, das vor einigen Jahren die ganze Softwarebranche zu kopieren versucht hat), legt diese Vermutung nahe. Ein Squad kümmert sich um Komponenten wie z.B. den Player – siehe diese Präsentation ↩︎

  4. In diesem Video erklärt Casey Muratori Conway’s Law anhand der fünf Lautsprecherregler von Windows ↩︎

Dieser Artikel erschien in Ausgabe 80 meines wöchentlichen Newsletters "Tech is Good". Du kannst ihn hier abonnieren.