Edsger Dijkstra: Warum Disziplin mehr zählt als Cleverness

6 Min. Lesezeit

Für ihn war Schlamperei ein Konstruktionsfehler

Das eigentliche Vergehen waren nicht Bugs, sondern Nachlässigkeit

Edsger W. Dijkstra wird oft auf einen Algorithmus, einen berühmten Brief über goto und seinen Ruf reduziert, schlampiges Denken nicht zu dulden. Der Ruf kam nicht von ungefähr.

Geboren 1930 in Rotterdam, wurde er 1952 am Mathematisch Centrum in Amsterdam offiziell zum ersten Programmierer der Niederlande. Später arbeitete er in Eindhoven, bei Burroughs und an der University of Texas at Austin. Unterwegs lieferte er uns den Kürzeste-Wege-Algorithmus, prägende Arbeiten zu Semaphoren und Betriebssystemen und einen Korpus von Essays, der bis heute genügt, um einen ganzen Raum professionell in die Defensive zu treiben.

Er hatte wenig Geduld mit der bis heute verbreiteten Gewohnheit, alles zu feiern, was in der Demo irgendwie läuft, und die harten Fragen erst dann zu stellen, wenn die Produktion schreit. Für Dijkstra lag das Kernproblem nicht darin, dass Programme manchmal Fehler enthalten. Das tiefere Problem war, dass Entwickler Unklarheit als normalen Zustand akzeptierten.

Darum treffen seine Texte bis heute. Er schrieb nicht wie ein Framework-Verkäufer oder Prozessberater. Er schrieb wie jemand, der gesehen hatte, was passiert, wenn Komplexität schneller wächst als Verstehen. Und dann weigerte er sich, die Verursacher dabei noch zu streicheln.

Strukturierte Programmierung war ein Aufstand gegen das Chaos

In den 1960er Jahren wurden große Programme zu verhedderten Massen aus Sprüngen, Flags, verstecktem Zustand und Kontrollfluss, denen nur ihre ursprünglichen Autoren folgen konnten. Die Maschine führte sie aus. Menschen litten darunter.

Dijkstras Brief von 1968, “Go To Statement Considered Harmful” wurde zum öffentlichen Symbol einer breiteren Bewegung; das zugrunde liegende Argument steht bereits in seinem früheren Essay A Case against the GO TO Statement. Der Slogan wurde schnell zu einem syntaktischen Kleinkrieg vereinfacht, wie so oft. Das eigentliche Argument war ernster. Wenn der Kontrollfluss überall hinspringen kann, wird das Nachdenken über ein Programm viel schwerer als nötig. Und wenn Nachdenken schwer wird, wird Qualität zum Theater.

Strukturierte Programmierung war keine Reinheitslehre. Es ging darum, Code zu schaffen, dessen Verhalten sich lokal verstehen, sicher zusammensetzen und diszipliniert prüfen lässt. Sequenz, Auswahl, Iteration, klare Grenzen, explizite Invarianten. Nicht weil das hübsch wirkt, sondern weil es den Raum verkleinert, in dem Software uns anlügen kann.

Dasselbe Argument hört man heute, wenn Teams eine überwucherte Codebasis zähmen wollen. Ersetze geisterhafte Fernwirkung durch klare Zuständigkeit. Entferne versteckte Kopplung. Verkleinere Funktionen so weit, bis sie eine Sache klar sagen. Hör auf, die Person zu feiern, die “einfach weiß”, wie der Schlamassel funktioniert.

Korrektheit beginnt vor dem Testlauf

Dijkstras Satz über Tests wird ständig zitiert und meistens zu flach verstanden. Er wollte Tests nicht abwerten. Er warnte vor magischem Denken.

Eine Test-Suite ist Evidenz. Gute Evidenz, manchmal ausgezeichnete. Sie ist keine Absolution. Wenn das zugrunde liegende Design inkohärent ist, wenn Verantwortlichkeiten über Schichten verschmiert sind, wenn Geschäftsregeln an sechs Stellen mit leicht anderer Formulierung dupliziert werden, dann beweist eine Wand grüner Haken womöglich nur, dass die Verwirrung die beprobten Randfälle noch nicht erreicht hat.

Diese Einsicht passt schmerzhaft gut zur heutigen Software. Viele Teams reden über Qualität, während das System strukturell nicht mehr vernünftig zu durchdenken ist. Sie stapeln End-to-End-Tests, Freigabeschritte und Pull-Request-Rituale aufeinander, weil sie der Form des Codes nicht trauen. Die Rituale kompensieren Designdefizite.

Dijkstra zog die Verantwortung konsequent weiter nach vorn. Vor dem Coden denken. Annahmen benennen. Den Kontrollfluss lesbar machen. Das mentale Modell klein genug halten, damit Korrektheit besprechbar bleibt statt mystisch zu werden.

Sein Algorithmus machte ihn berühmt. Sein Maßstab war höher.

Ja, Dijkstra gab uns den Kürzeste-Wege-Algorithmus, dem früher oder später jeder Informatikstudent begegnet. Ja, er arbeitete an Semaphoren, gegenseitigem Ausschluss, Deadlock-Vermeidung, selbststabilisierenden Systemen und grundlegenden Ideen für Programmiersprachen und verteilte Systeme. Der Lebenslauf ist absurd.

Aber die Software-Entwicklung brauchte nicht in erster Linie noch ein Genie, das ein schwieriges mathematisches Problem lösen konnte. Sie brauchte jemanden, der darauf bestand, dass gewöhnliche Programmierung aufhört, ein Sumpf aus cleveren Ausnahmen und improvisierten Fluchtwegen zu sein.

Darum hämmerte er so auf Eleganz, Einfachheit und Disziplin ein. Nicht als ästhetischer Luxus. Sondern als betriebliche Notwendigkeit. Komplexe Systeme enthalten ohnehin genug unvermeidliche Schwierigkeit. Darüber hinaus noch vermeidbare Verwirrung zu schichten, ist professionelle Fahrlässigkeit mit besserem Branding.

Der Kult um den Heldenentwickler hätte ihn genervt

Ein großer Teil moderner Softwarefolklore kreist noch immer um den Heldenentwickler. Die Person, die den versteckten Schalter kennt. Die Person, die Produktion um zwei Uhr morgens flicken kann. Die Person, die allein die Billing-Engine, die Deployment-Pipeline oder die verfluchte Integration versteht, die niemand anzufassen wagt.

Dijkstra hätte darin kein Heldentum gesehen, sondern einen Führungs- und Designfehler.

Software sollte nicht von Mystik abhängen. Sie sollte keine rituelle Einweihung verlangen. Wenn das Verständnis des Systems von Stammeswissen und fragiler Prestigeökonomie abhängt, hat die Organisation ein Statusspiel auf Basis von Intransparenz gebaut.

Darum reicht seine Relevanz weit über Syntaxdebatten hinaus. Er argumentierte für eine professionelle Kultur, in der Entwickler versehentliche Komplexität abbauen, statt sie in persönliche Hebelwirkung zu verwandeln. Der Gewinn ist nicht nur technische Qualität. Es ist organisatorische Vernunft.

Was Dijkstra uns immer noch lehrt

Dijkstras Botschaft bleibt, weil Software die Zustände ständig neu erzeugt, die ihn wütend machten.

Wir verherrlichen noch immer Cleverness, wo Klarheit besser dienen würde.

Wir lassen Architektur noch immer so weit auswuchern, bis Teams Zeremonien brauchen, um sich um vermeidbare Verwirrung herum zu koordinieren.

Wir verwechseln noch immer nachträgliches Testen mit diszipliniertem Design.

Wir belohnen noch immer den Hüter des Labyrinths stärker als die Person, die eine Mauer entfernt.

Die bleibende Lehre ist nicht, dass jedes Programm mathematisch makellos aussehen muss. Reale Systeme sind unordentlicher als Manifeste. Die Lehre ist, dass Software besser wird, wenn wir Verständlichkeit als harte Nebenbedingung behandeln. Klarheit ist keine Dekoration. Sie ist eine Voraussetzung für Korrektheit, Zusammenarbeit und langfristige Geschwindigkeit.

Dijkstra forderte nicht weniger Ehrgeiz von Entwicklern. Er forderte, dass wir aufhören, von den falschen Dingen beeindruckt zu sein.

Referenzen

Dijkstra mochte Bibliografien nicht besonders. Diese hier ist für den Rest von uns.

• Edsger W. Dijkstra Archive, University of Texas at Austin
• A Case against the GO TO Statement (EWD215)
• On the reliability of programs (EWD303)
• ACM-Turing-Award-Würdigung für Edsger W. Dijkstra
• Biografischer Überblick: Edsger W. Dijkstra bei MacTutor