“What kind of programmer is so divorced from reality that she thinks she’ll get complex software right the first time?”
James Alan Gardner
Das von John Gall schon 1975 in seinem Buch Systemantics: How Systems Work and Especially How They Fail aufgestellte Gesetz, ist eine der vielen wichtigen Faustregeln, die jeder System-Architekt und Software-Entwickler kennen sollte. Obwohl schon fast 50 Jahre alt, wird es von vielen Kollegen stoisch ignoriert.
“A complex system that works is invariably found to have evolved from a simple system that worked. The inverse proposition also appears to be true: a complex system designed from scratch never works and cannot be made to work. You have to start over, beginning with a simple system.”
John Gall
Was besagt nun Gall’s Law? Zum einen sagt es aus, dass alle funktionierenden komplexen Systeme aus einfacheren funktionierenden Systemen entstanden sind. Wer in der agilen Software Entwicklung arbeitet, wird diese Aussage nicht anzweifeln können. Immerhin ist es eines der zentralen Paradigmen, ohne das eine inkrementelle und iterative Arbeitsweise nicht möglich wäre.
Andererseits postuliert Gall’s Law, dass es nicht möglich ist, ein komplexes System nach einem Entwurf umzusetzen. Der Versuch wird scheitern und ein neuer Versuch wird mit einem einfachen Entwurf gestartet.
Warum sollten keine komplexen Software Systeme erstellt werden können, aber Flughäfen wie BER und Konzerthäuser wie die Elbphilharmonie schon? Zum einen zeigen die Beispiele, dass es auch bei Hardware Projekten zu Schwierigkeiten kommen kann, andererseits ändern sich die Anforderungen beim Bau eines Konzerthauses nicht besonders drastisch.
“Walking on water and developing software from a specification are easy if both are frozen.”
Edward V Berard
Ganz offensichtlich bereiten die Anforderungen an ein Software System Schwierigkeiten, weil diese sich immer wieder ändern. Neben den expliziten Anforderungen gibt es noch viele weitere Umweltbedingungen, denen sich ein System unterwerfen muss. Josh Kaufman spricht in dem Zusammenhang von Environmental Selection Tests. Nur Systeme, die all diese Tests bestehen, können sich für eine Weile behaupten.
Zu den Selektionstests gehören Marktanforderungen, Benutzererwartungen, Technologietrends, Entwicklungskosten, Wartungskosten, Ergonomie, Features, etc. Einige dieser Anforderungen sind nicht vorhersehbar, andere sind in Abhängigkeit zu anderen, widersprechen sich gegebenenfalls und müssen abgewogen werden. Es sollte klar werden, dass sich hier ein kombinatorisches Problem offenbart. Mehr Anforderungen bedeutet eine nichtlineare Vergrößerung der Komplexität. Im schlimmsten Fall explodiert die Komplexität mit der Fakultät der Anforderungen.
“Some people, when confronted with a problem, think ‘I know, I’ll use regular expressions.’ Now they have two problems.”
Jamie Zawinski
Vor vielen Jahren durfte ich einen Fehler in einen Dokumenten Management System beheben. Eine Suche nach Wordkombinationen in einem frei wählbaren Fenster umfasste nicht alle Kombinationen. Da die Kollegen darauf bestanden, die Lösung mit Regulären Ausdrücken zu erstellen, konnte die Funktion nur beschnitten werden, statt zu verbessern. Die abgelehnte Lösung war mit einem Word-Index des Dokuments schnell erstellt, basierte aber nicht auf Regulären Ausdrücken.
Die Kollegen wollten damals nicht einsehen, dass Reguläre Ausdrücke keine sinnvolle Lösung waren, weil sie die kombinatorische Explosion und damit die extreme Vergrößerung der Ausdrücke ignorierten. Die Kombinationsmöglichkeiten von drei Wörtern ist Fakultät von 3, also 1*2*3=6, die Fakultät von 5 ist aber schon 120 und die Fakultät von 10 unglaubliche 3.628.800.
Große Software-Systeme entstehen ganz offensichtlich durch die gleichen Phänomene, die Richard Dawkins in seinem Buch “The Blind Watchmaker” beschrieben hat. Ein Software-System unterliegt wie ein Lebewesen der Selektion. Wo ein Lebewesen um Nahrung konkurrieren muss, ist es bei dem Software-System der zufriedene User. Während die Lebewesen in jeder neuen Generation weitere Variationen hervorbringen, die den aktuellen Umweltbedingungen besser oder schlechter angepasst sind, gibt es bei Software-Systemen neue Releases, die Marktanforderungen besser oder schlechter erfüllen.
Durch kommulative Selektion ergibt sich dann über viele Patches ein Software-System, das E-Mails lesen kann oder ein Pan Narrans, der Blog-Beiträge schreibt.
Am Ende fragt man sich jedoch, warum planen wir dennoch immer wieder neue große Lösungen, statt den ersten iterativen Schritt zu tun? Manchmal ist es die Unwissenheit über die Schrecken der Komplexität, manchmal ist es die Angst Fehler zu machen und manchmal ist es die eigene Hybris, die uns ein Bein stellt.