Software-Komplexität ist ein Thema, das in der Softwareentwicklung seit Jahrzehnten intensiv diskutiert wird. Welche Faktoren machen Software wirklich komplex? Wie kann man Komplexität messen, einschätzen oder gar reduzieren? In der Praxis stehen Entwickler, Architekturverantwortliche und Manager häufig vor der Herausforderung, den Überblick über komplexe Systeme zu behalten und diese effizient zu warten oder weiterzuentwickeln. Dabei bleibt die Frage bestehen: Was genau verstehen wir unter Komplexität? Unterschiedliche Experten und Vordenker haben hierzu variierende, teils sich ergänzende Definitionen entwickelt. Ein genauer Blick auf drei prominente Perspektiven – die von Rich Hickey, John Ousterhout und Zach Tellman – hilft, den Begriff Software-Komplexität vielseitiger und praxisnaher zu verstehen. Dabei wird deutlich, wie sehr subjektive und objektive Facetten ineinandergreifen und wie entscheidend die Sichtweise für den Umgang mit Software ist.
Rich Hickey, bekannt als Entwickler der Programmiersprache Clojure, setzt bei seiner Definition von Komplexität auf einen eher objektiven Ansatz. Er beschreibt „Einfachheit“ als das Prinzip von „Oneness“ – zu Deutsch: Einheitlichkeit oder Einfalt. Das bedeutet, etwas ist einfach, wenn es eine klare, fokussierte Aufgabe, Rolle oder Dimension besitzt, ohne dass unterschiedliche Aspekte miteinander verknüpft oder „verwirrt“ sind. Hickey führt dafür das Wort „complect“ ein, um ein unvorteilhaftes Verflechten zu beschreiben, welches die Verständlichkeit erschwert. Seine Opposition steht dem „compose“ gegenüber, also dem bewussten und strukturierten Zusammenfügen von Elementen.
Für Hickey ist Einfachheit also nicht gleichbedeutend mit geringen Anzahl der Teile, sondern vielmehr eine Frage der fehlenden Verflechtungen und Interdependenzen. Daraus folgt, dass Software mit vielen Komponenten, die stark miteinander verwoben sind, hoch komplex ist. Interessanterweise unterscheidet Hickey konsequent zwischen „einfach“ und „leicht“ („easy“). Letzteres bezieht sich mehr auf subjektive Faktoren wie Erfahrung, Vertrautheit oder Zugänglichkeit, die von Person zu Person variieren. Demgegenüber ist „einfach“ für ihn eine objektive Eigenschaft des Systems, die durch Analyse erkennbar ist – ein Stück Software kann also objektiv einfach, aber für Nutzer aufgrund Fehlens von Routine schwer zu verstehen sein.
Seine Forderung nach Einfachheit zielt vor allem darauf ab, Komplexität zu minimieren, um Verständnis, Änderbarkeit und Flexibilität von Software zu erhöhen. Beispiele aus der Clojure-Umgebung zeigen dabei, wie funktionale Werte gegenüber Objekten mit Zustand bevorzugt werden, da Zustandsmanagement „niemals einfach“ sei. Im Gegensatz dazu definiert John Ousterhout, Professor und Autor von „A Philosophy of Software Design“, Komplexität als alles, was eine Software schwer verständlich und änderbar macht. Sein Fokus liegt deutlich auf der praktischen Erfahrung von Entwicklern. Dabei betont er besonders Obviousness – also die offensichtliche Nachvollziehbarkeit von Code.
Ein System gilt als offensichtlich, wenn Entwickler es schnell einsehen, Änderungen ohne großes Nachdenken durchführen können und im Wesentlichen „richtig raten“, wie das System funktioniert. Aus Ousterhouts Sicht ist mangelnde Transparenz, unklare Abhängigkeitsbeziehungen und mangelnde Konsistenz die Hauptursache für Komplexität. Er spricht von zwei zentralen Ursachen: Dependencies (Abhängigkeiten) und Obscurity (Unklarheit). Dependencies entstehen, wenn Codeabschnitte nicht isoliert betrachtet werden können, sondern in einem Beziehungsgeflecht stehen, das ebenfalls berücksichtigt werden muss. Obscurity liegt vor, wenn wichtige Informationen nicht offensichtlich sind, zum Beispiel durch generische Variablennamen oder unvollständige Dokumentation.
Besonders prägnant sind seine beschriebenen Symptome von Komplexität: Änderungsamplifikation (eine scheinbar einfache Änderung zieht viele Anpassungen nach sich), kognitive Überlastung (hoher mentaler Aufwand für Entwickler) und unbekannte Unbekannte (nicht klar, welche Auswirkungen eine Änderung haben kann). Ousterhout betont, dass Komplexität subjektiv in den Köpfen der Leser entsteht und intuitive Lesbarkeit ein entscheidendes Kriterium für gutes Design ist. Als dritten Blickwinkel finden sich die Überlegungen von Zach Tellman, der in seinem Newsletter „Explaining Software Design“ einen besonders kommunikativen Ansatz verfolgt. Für Tellman ist Komplexität das „Summe aller Erklärungen“, die nötig sind, um Software zu verstehen und zu verändern – dabei werden zukünftige Erklärungen besonders gewichtet. Seine Definition ist somit stark subjektiv und kontextabhängig, denn Komplexität misst er relativ zum Publikum und dessen Erwartungen.
Unter „Erklärung“ versteht Tellman sowohl die konkreten Hilfsmittel wie Dokumentationen, Commit-Nachrichten und Kommentare als auch die geistigen Prozesse des Verstehens und des Weitervermittelns. Eine zentrale Rolle spielt bei ihm das Konzept der „Überraschung“ (Surprisal): Je unerwarteter ein Sachverhalt für den Betrachter ist, desto höher die Komplexität. Dabei betrachtet Tellman Systemerklärungen als drei Teile: das Vorwissen (Prefix), den gegenwärtigen Inhalt (Content) und die zukünftig erwarteten Erläuterungen (Suffix). Interessant ist auch seine Sichtweise zum Thema Kopplung. Anstatt Kopplung aus moralischer Perspektive zu bewerten, sieht Tellman sie als Werkzeug.
Zwei Konzepte sollten gekoppelt werden, wenn sie oft gleichzeitig erklärt werden müssen. So wendet Tellman diese Idee auf moderne Probleme wie verteiltes Tracing an: obwohl distributed tracing die Abhängigkeiten im System erhöht, kann es sinnvoll sein, weil es hilft, komplexe Zusammenhänge transparent zu machen. Betrachtet man diese drei Perspektiven nebeneinander, erkennt man unterschiedliche Schwerpunkte und Implikationen für die Praxis. Der objektive Ansatz von Hickey legt den Grundstein für eine klare, technische Reduktion von Komplexität durch „Entflechtung“. Allerdings lässt das die subjektive Erfahrung vieler Entwickler bei der Einarbeitung und im Alltag außer Acht.
Ousterhouts Definition greift eben diese subjektiven Faktoren auf und stellt die Verständlichkeit für Menschen in den Mittelpunkt, geht aber in seinen Ausführungen an manchen Stellen selbst sehr kritisch und wenig nuanciert mit gegensätzlichen Sichtweisen um. Tellmans Ansatz erweitert die Diskussion um den kommunikativen Aspekt: Software-Komplexität ist auch ein Kommunikationsproblem, ein ständiger Prozess des Erklärens und Verstehens in Teams. Besonders für heterogene Entwicklerteams mit unterschiedlichen Erfahrungsniveaus bietet seine Perspektive praktische Anknüpfungspunkte. Ein spannendes Anwendungsfeld ist die Personalführung und Teamzusammenstellung. Wenn neue Entwickler an Bord kommen und Schwierigkeiten haben, weil die Software als zu komplex wahrgenommen wird, können die drei Sichtweisen unterschiedliche Handlungsempfehlungen geben.
Hickeys objektiver Blick würde eine Vereinfachung der Codebasis nahelegen, wenn sie wirklich stark verknüpft und kompliziert ist. Ousterhout würde auf die subjektiven Probleme der Lesbarkeit und offensichtlichen Struktur verweisen und raten, diese zu adressieren. Tellman hingegen schlägt vor, Kommunikationswege zu optimieren, mehr Erklärungen zu liefern oder Aufgaben präziser zu vermitteln, um so die subjektiv empfundene Komplexität zu reduzieren. In der Praxis kombiniert sich Komplexität aus vielen Faktoren und individuellen Erfahrungen. Ein allumfassendes Modell fehlt bislang, aber das Zusammenspiel der genannten Perspektiven hilft, komplexe Probleme zu verstehen und gezielt anzugehen.
Die Verantwortung, Komplexität zu managen, liegt nicht nur bei Einzelpersonen, sondern bei Teams und Organisationen. Bewusstes Design, saubere Trennung von Verantwortlichkeiten, klare Kommunikation und regelmäßiges Reflektieren der bestehenden Systeme sind wichtige Prinzipien zur Begrenzung von Komplexität und Erhöhung der Produktivität. Die Debatte über Komplexität ist auch eine kulturelle Diskussion über Erwartungen, Handling von Wissen und Kooperation in der Softwareentwicklung. Während Einfachheit und Verständlichkeit generell angestrebt werden, müssen dabei Unschärfen und Kompromisse akzeptiert werden. Praktisch bedeutet dies, dass Teams sowohl objektive Metriken als auch subjektive Einschätzungen berücksichtigen sollten und mit genügend Flexibilität auf sich verändernde Rahmenbedingungen reagieren.
Besonders wichtig ist das Bewusstsein, dass Komplexität nicht einfach „wegprogrammiert“ werden kann, sondern ein Organismus ist, der aus Code, Menschen, Kommunikation und Prozessen entsteht. Wer diese Tiefe anerkennt, ist besser gewappnet, um nachhaltige, verständliche und wartbare Software zu gestalten. Insgesamt zeigt die Analyse der drei unterschiedlichen Definitionen von Software-Komplexität, dass es nicht die eine richtige Antwort gibt. Vielmehr ergänzen sich die Perspektiven und bieten ein breites Spektrum an Werkzeugen und Begriffen, um das Phänomen umfassend anzugehen. Für Entwickler und Führungskräfte heißt das, Komplexität nicht als abstrakte Herausforderung, sondern als konkretes, greifbares Problem mit präzisen Facetten wahrzunehmen.
Nur so lassen sich die Herausforderungen moderner Softwareentwicklung meistern und innovative, langlebige Systeme bauen.
