In der Welt der Softwareentwicklung und Organisationen werden immer wieder bestimmte Weisheiten und Zitate zitiert, die sich zu wahren Mantren entwickelt haben. Doch häufig werden ihre Ursprünge, Bedeutungen und vor allem die tieferen Einsichten, die sie bereithalten, übersehen oder missverstanden. Ein genauer Blick auf diese oft zitierten Aussagen offenbart verborgene Wahrheiten, die für Entwickler, Führungskräfte und Organisationen von enormer Bedeutung sind. Die Themen reichen dabei von Gall’s Law über Wirth’s Law bis hin zu weniger bekannten Weisheiten wie Perlis’ Third Epigram. Diese Konzepte bieten nicht nur technische Einsichten, sondern spiegeln auch tiefere menschliche und organisatorische Aspekte wider, die oft in der rasanten Welt der Technologieentwicklung untergehen.
Gall’s Law gilt als eine der einflussreichsten Aussagen im Bereich komplexer Systeme. Im Kern besagt es, dass ein komplexes System, das funktioniert, immer aus einem einfachen, funktionierenden System evolviert ist. Diese Erkenntnis mag zwar allgemein bekannt sein, doch oft wird ein wichtiger Zusatz, eine Art Korollar, übersehen. Es besagt, dass ein komplexes System, das von Grund auf neu entworfen wird, nie funktionieren kann und nicht zum Funktionieren gebracht werden kann. Stattdessen muss man immer mit einem einfachen, funktionierenden System beginnen und dieses iterativ weiterentwickeln.
Was viele nicht wissen: John Gall war kein Ingenieur, sondern sprach in seinem Buch "Systemantics" vor allem über menschliche Organisationen und Systeme wie die Vereinten Nationen oder die Liga der Nationen. Seine Beobachtungen sind weniger technische Gesetze im engen Sinne, sondern Erfahrungswerte über die Komplexität menschlicher Gruppendynamik. Gall kritisierte die stark systemtheoretisch geprägten damaligen Ansätze zur Organisationsgestaltung, die versuchten, menschliches Verhalten und Gruppenprozesse mittels starrer mathematischer Modelle zu steuern. Seine Aussagen sind eher Warnungen vor der Übervereinfachung menschlicher Komplexität und vor dem blinden Vertrauen auf grafisch ansprechende, aber inhaltlich hohle Leistungskennzahlen. Gerade in der Softwarebranche, die häufig von ineffektiven und durchstrukturierten Organisationsmodellen geprägt ist, kommt Gall’s Law eine besondere Relevanz zu.
Wenn in Meetings Diagramme mit Begriffen wie "Fehlerbehebungsrate" auftauchen, dann ist das oft ein Indikator für eine dysfunktionale Umsetzung komplexer Systeme, die Gall thematisiert hat. Im direkten Zusammenhang damit steht Wirth’s Law, das häufig missverstanden wird. Oft liest man die verkürzte Version, dass Software langsamer werde, als Hardware schneller werde. Ursprünglich stammt das Zitat nicht einmal von Niklaus Wirth selbst, sondern von Martin Reiser, der in einem Vorwort zu einer frühen Computeranleitung diese Beobachtung machte. Wirth griff diesen Gedanken auf, um auf ein gravierenderes Problem hinzuweisen: Die zunehmende Überfrachtung von Software mit Funktionen, einem Phänomen, das oft als „Software-Bloat“ bezeichnet wird, ist nicht nur eine Frage der Performance, sondern vor allem ein Zeichen schlechter Planung und Geschäftsstrategie.
Bloat entsteht durch die Fixierung auf stetige Erweiterung der Funktionalität, ohne dabei die eigentlichen Kundenbedürfnisse und die Nutzbarkeit zu betrachten. Oft bevorzugen Softwarehersteller inkrementelle, unsaubere Lösungen, Standards, die sich als ineffizient herausstellen, oder setzen darauf, dass Kunden vom Anbieter abhängig bleiben, weil die Software nur durch den Hersteller sinnvoll erweitert oder angepasst werden kann. Das Ergebnis ist eine Maschine, die einerseits mit Funktionalität überladen und dadurch komplex ist, andererseits aber wenig flexibel und schwer wartbar, fehleranfällig sowie unperformant bleibt. Wirth und Reiser betonen, dass solche Probleme nicht allein durch bessere Hardware gelöst werden können. Es liegt ein grundlegendes Problem in der Ausrichtung von Entwicklung und Geschäftsstrategien vor, bei dem Qualität, Klarheit und nachhaltige Wartbarkeit oft hinter kurzfristigen Erfolgsmetriken zurückstehen.
Dabei ist das Beispiel des Oberon-Systems besonders aussagekräftig. Oberon bot durchaus viele Funktionen, war aber so gestaltet, dass es leicht verständlich, erweiterbar und effizient blieb. Das spricht für eine bewusste Auswahl der Features und deren Zusammenspiel, die weit über reines Feature-Counting hinausgeht. Ein weiteres Beispiel für missverstandene Technikweisheit ist die vermeintliche Aussage von Bill Gates, dass 640 KB Arbeitsspeicher für jeden Nutzer ausreichen müssten. Unabhängig davon, ob dieses Zitat tatsächlich so gefallen ist, liegt in der Geschichte dahinter eine wichtige Lehre.
Microsoft hatte für das IBM-PC-Design die untere 640-Kilobyte-Speichergrenze für den allgemeinen Gebrauch bestimmt, wobei die oberen 384 KB für Systemfunktionen und Hardware reserviert waren. Das war damals eine erstaunliche Menge an RAM – zehnmal mehr als allgemein verfügbar. Das eigentliche Problem war nicht die technische Grenze, sondern dass dieser sogenannte Sicherheitsfaktor in der Praxis gar keiner mehr war, sobald Preise und Anforderungen stiegen. Innerhalb weniger Jahre war der Speicherpreis so stark gesunken, dass Nutzer einfach mehr RAM einbauen konnten. Die vorgesehene Reserve war damit praktisch nicht vorhanden.
Die Lehre daraus liegt weniger im Absehen zukünftiger Anforderungen als in der Bedeutung von Sicherheitsfaktoren in ingenieurtechnischen Lösungen und der Notwendigkeit, diese wirklich zukunftssicher zu planen und so auszulegen, dass sie in der Praxis auch funktionieren. Auf einzigartige Weise bringt auch Perlis’ Third Epigram, ein oft zitierter Spruch aus der Informatikgeschichte, einen erhellenden, aber häufig missverstandenen Gedanken zum Ausdruck. Der Ausspruch, „syntaktischer Zucker führt zum Krebs des Semikolons“, klingt zunächst wie eine leichte Mahnung gegen zu viel syntaktischen Zucker in Programmiersprachen, also besondere Sprachkonstrukte, die den Code für den Nutzer vereinfachen. Was aber dahinter steckt, ist eine tiefere Erkenntnis zur Spracheentwicklung und Compilerbau, besonders geprägt durch Erfahrungen mit ALGOL, der Sprache, die den Semikolon als Anweisungstrenner einführte. ALGOL hatte zunächst eine problematische Grammatik, die Leeranweisungen und damit aufeinander folgende Semikolons erlaubte, was zu Komplexität und Mehrdeutigkeit führte.
Solcher syntaktische Zucker verursacht unter der Oberfläche zusätzliche Komplexität für Compilerentwickler, führte zu Bugs und zwang die Nutzer bisweilen zu expliziten Klarstellungen und Workarounds. Dieser unsichtbare Preis der Vereinfachung zeigt, dass Innovationen in der Sprachgestaltung eine Gratwanderung sind. Verbesserungen für den Nutzer müssen gegen die technische Komplexität bei Interpretation und Übersetzung abgewogen werden. Manchmal wirkt sich der syntaktische Zucker negativ auf die Wartbarkeit und Verständlichkeit aus, und die Lösung für die Entwickler führt zu mehr Aufwand statt zu weniger. Diese kritischen Einsichten zeigen, wie wichtig es ist, gängige Weisheiten nicht nur als Schlagworte oder Meme zu behandeln, sondern die zugrundeliegenden Bedeutungen und Kontexte zu verstehen.
Gerade in einer Zeit, in der Technologieentwicklung immer schneller voranschreitet und komplexe Organisationen immer unübersichtlicher werden, kann die falsche Interpretation von Beobachtungen zu Fehlentscheidungen führen – sei es bei der Gestaltung von Softwarearchitekturen, organisatorischen Prozessen oder technischen Standards. Gall’s Law erinnert uns daran, dass nachhaltiger Erfolg mit einfachen, funktionierenden Systemen beginnt und iterative Verbesserung die einzige realistische Strategie ist. Wirth’s Law dagegen warnt vor der Fallstrick von Ausuferung und dem Mangel an Klarheit in Features und Design. Die Geschichte von 640 KB Speicher mahnt dazu, technische Entwürfe zukunftssicher zu planen und Sicherheitsreserven realistisch zu bemessen. Und Perlis’ Epigram zeigt auf, dass Vereinfachung und Schönheit eines Systems oft einen unsichtbaren Preis haben.
In der Praxis bedeuten diese Erkenntnisse, dass Softwareteams und Organisationen ihre Entwicklungsmethoden und Managementstrategien kritisch hinterfragen sollten. Statt blind neuen Trends zu folgen oder vermeintlich etablierten Weisheiten zu verfallen, ist es wichtig, diese Weisheiten zu verstehen und im eigenen Kontext anzuwenden. Nur so lassen sich echte technische und organisatorische Herausforderungen meistern. Darüber hinaus spiegeln diese Weisheiten eine menschliche Komponente wider, die in technischer Forschung und Entwicklung oft vernachlässigt wird. Menschen, ihre Verhalten, Kommunikation und Entscheidungen bestimmen maßgeblich den Erfolg komplexer Systeme.
Die beste Technik nutzt wenig, wenn Organisationen und Teams nicht lernfähig und anpassungsfähig bleiben. Insgesamt laden diese wertvollen Nuggets of Wisdom – oft missverstanden und teilweise als Anekdoten abgetan – zu einer tiefgründigen Reflexion über Technik, Organisation und Menschsein ein. Ihre wahre Bedeutung liegt nicht im reinen Zitieren, sondern im Verstehen und beherzigen. Wer sich dieser Erkenntnisse annimmt, verfügt über einen entscheidenden Vorteil in der dynamischen Welt der Softwareentwicklung und darüber hinaus.
