Beten wir Komplexität an?

Inhaltsverzeichnis

Komplexität ist die zentrale Herausforderung in der Softwareentwicklung. Daher gilt es, immer bestrebt sein, Komplexität zu eliminieren. Schließlich sollten wir immer lieber einfache Probleme lösen wollen als komplexe. Aber manchmal beten wir Komplexität an – und das kann Komplexitätsprobleme unlösbar machen.

In der Softwareentwicklung geht es nur scheinbar ums Programmieren. Einen Zehnzeiler kann jeder schreiben. Das Problem sind komplexe Systeme. Wenn ein System so groß ist, dass ein einzelner Mensch allein es nicht verstehen und weiterentwickeln kann, sind Konzepte wie Modularisierung entscheidend. Modularisierung teilt das System in kleine Einheiten auf, die ein Mensch weiterentwickeln kann. Dann wird Komplexität entscheidend. Aber bei solcher Komplexität können Einzelpersonen keine Projekte mehr durchführen, sondern nur noch Teams. Das führt zu organisatorischen Herausforderungen.

Das Gesetz von Conway

Wichtig ist in diesem Zusammenhang das Gesetz von Conway. Es besagt, dass die Architektur eines Systems die Kommunikationsstrukturen der Organisation abbildet, die das System umsetzt. Für jedes Modul in der Software gibt es also eine Einheit in der Organisation und für jede Kommunikationsbeziehung zwischen Organisationseinheiten eine Abhängigkeit zwischen den Modulen in der Software.

In Conways Paper von 1968 ist aber noch etwas anderes beschrieben: Wenn eine Organisation ein großes System entwickeln will, dann muss sie viele Leute in das Projekt holen. Da Kommunikation in einem großen Team schwierig ist, bricht sie ab einer bestimmten Teamgröße zusammen. Da Kommunikation und Architektur sich gegenseitig beeinflussen, führt die mangelhafte Kommunikation zu einer chaotischen Architektur und zusätzlicher Komplexität.

Conway geht aber weiter: Offensichtlich sollte man sich, wenn irgend möglich, auf elegante Lösungen fokussieren, die ein kleines Team umsetzen kann. Aber das Prestige eines Managers hängt von der Größe des Teams und des Budgets ab, für das er oder sie zuständig ist, so Conway. Daher wird ein Manager möglichst ein großes Team und ein großes Budget anstreben.

Das scheint zunächst kein Problem zu sein. Wenn das Projekt eigentlich mit einem kleineren Team gelöst werden kann, sitzen eben einige rum. Das kostet Geld, gefährdet aber Projekt und Architektur nicht. Conway sagt aber, dass das Parkinsonsche Gesetz zuschlägt. Parkinson erklärt mit dem Gesetz, warum einige Verwaltungen zwar mehr Mitarbeiter einstellen, aber trotzdem nicht mehr leisten. Dieses Gesetz besagt, dass eine Aufgabe die zur Verfügung stehende Zeit aller Mitarbeiter vollständig ausfüllt. Auch wenn die Aufgabe einfach und schnell bearbeitet werden kann, beteiligen sich immer mehr Personen daran, bis alle Personen in der Organisation mit Arbeit versorgt sind. In einem Software-Projekt werden also alle Teammitglieder an dem Projekt arbeiten, unabhängig davon, ob das notwendig ist. Dementsprechend wird dann die Organisation groß werden, die Kommunikation gegebenenfalls zusammenbrechen und die Architektur chaotisch werden

Die Erkenntnis von Conway, die mittlerweile 50 Jahre alt ist, ist vor allem interessant, weil sie eine Erklärung dafür sein kann, wenn ein großes wichtiges Projekt eine schlechte Architektur hat und schwer weiterentwickelt werden kann.

Die Manager aus diesem Paper beten Komplexität an, ohne dass ihnen das klar ist. Sie wollen ein möglichst großes Team und machen so ein Problem zu komplex, weil eine große Organisation die Architektur zusammenbrechen lassen kann.

Und die Softwarearchitekten?

Aber nicht nur Manager, sondern auch wir Softwarearchitekten beten manchmal Komplexität unbewusst an. Das passiert beispielsweise, wenn wir unreflektiert Patterns wie Event Sourcing, Architekturen mit vielen Schichten oder Microservices nutzen, ohne den Nutzen in dem spezifischen Kontext und die Komplexität genügend abzuwägen.

Auch der Technologie-Spieltrieb kann zu überbordender Komplexität führen. Schließlich suchen wir alle technische Herausforderungen und wollen besonders spannende Projekte umsetzen. Dazu sind moderne Ansätze und besonders komplexe Systeme gut geeignet. Ebenso lösen wir manchmal technische Probleme, die sich eigentlich gar nicht stellen. So entstehen sehr generische oder skalierbare Lösungen, die von den tatsächlichen Anforderungen so nicht gefordert werden und dadurch zu viel Komplexität erzeugen.

Komplexität als Entschuldigung

Ein besonders krasser Fall von Komplexitätsanbetung ist die Aussage "Das funktioniert bei uns nicht. Unsere Herausforderungen sind viel größer als die von Amazon oder Google." Ich habe das schon von Mitarbeitern unterschiedlicher Unternehmen gehört. Solche Äußerungen sind verwunderlich: Unternehmen wie Amazon oder Google betreiben ausgesprochen komplexe IT-Systeme und ihr wirtschaftlicher Erfolg hängt unmittelbar von diesen IT-Systemen ab. Sie gehören nicht zuletzt wegen dieser IT-Systeme zu den wertvollsten Unternehmen der Welt.

Auf den ersten Blick kann man die Äußerungen als Abwehrhaltung interpretieren: Amazon und Google haben eine moderne Organisation und eine Cloud-Infrastruktur, aber in der noch viel komplexeren Umgebung des Unternehmens geht das alles leider nicht. Aber vielleicht schwingt Stolz mit, denn schließlich kümmert man sich um nahezu beispiellose Herausforderungen. So oder so gilt auch hier: Die Komplexität hat zwar natürlich Nachteile, aber eben auch den Vorteil, dass man sich eben mit bestimmten Ansätzen wie Cloud, Continuous Delivery oder Microservices nicht beschäftigen muss, weil das ja eh nicht geht.

Es ist also fraglich, ob wir Komplexität wirklich immer vermeiden. Sich nur auf Techniken zu konzentrieren, Entwürfe möglichst einfach und elegant zu machen, nützt nichts, wenn wir unbewusst Komplexität doch anbeten. Deswegen ist es wichtig, sich über diese unbewussten Mechanismen klar zu werden. Natürlich gibt es dennoch viele komplexe Probleme, die tatsächlich schwer zu lösen sind.

Vielen Dank an meine Kollegen Jens Bendisposto, Jochen Christ, Lutz Hühnken, Michael Vitz und Benjamin Wolf für die Kommentare zu einer früheren Version des Artikels.

tl;dr

In der Softwareentwicklung geht es vor allem darum, Komplexität zu handhaben. Am besten wäre es, Komplexität gleich zu vermeiden. Aber leider kommt es manchmal zur – bewussten oder unbewussten – Komplexitätsanbetung, die zu unnötig komplexen Systemen führt. ()