Ralf philosophiert in seinem aktuellen Blog-Eintrag über sich entwickelnde Softwarestrukturen und versucht dabei eine Analogie zur Evolution im Speziellen und zur Natur im Allgemeinen aufzubauen.
Während seine Gedanken in der Basis sicher richtig sind und sich daraus Vieles ableiten lässt, sollte dabei ein wichter Punkt nicht vergessen werden: Obwohl die Natur unzählbare Iterationen Zeit hatte, um sich in ihrer Vielfalt bis zu dem heutigen Stand zu entwickeln, gibt es dennoch immer wieder "Bugs" - und damit meine ich nicht diese kleinen possierlichen Tierchen, die einst in einem Großrechner ihr Unwesen trieben.
Das Leben und seine Altlasten
Ralf schreibt, "alles an allen Organismen hat einen Zweck, den es erfüllt, so wie es ist. Da ist nichts zuviel, nichts zuwenig." Leben sei "insofern “lean”".
Das stimmt nicht ganz. Meiner Meinung nach muss man dieses Thema von zwei Seiten betrachten. Denn was das betrifft, hält die Natur sicher keinen etwaigen "Steckplatz" für einen weiteren Fingersatz an den Händen bereit (unter der Annahme, er könne mal gebraucht werden),... auf der anderen Seite wiederum halten unsere (rezessiven) Gene aber wiederum eine Menge Informationen bereit, die inaktiv sind.
Das ist in dem Sinne nicht einmal auskommentierter Code sondern lediglich Code, der nicht mehr angesprungen wird (unsere Compiler meckern heutzutage über so etwas). Genau das führt eben häufig zu "Systemfehlern", indem eigentlich rezessive Gene gelegentlich eben doch mal wieder aktiviert werden und aufgrund veränderter Umweltbedingungen den Mechanismus der evolutionsbedingten Anpassung teilweise aushebeln.
Im übertragenen Sinne fühlt sich das an, wie ein Entwickler, der wider besseren Wissens obsoleten Code nutzt oder Methoden verwendet, die eigentlich brachliegen... nur hat keiner darauf hingewiesen, dass das auch so gewollt ist.
Warum passiert so etwas in der Entwickler-Welt? Häufig, weil keine Quellcode-Versionierung verwendet wird und die Entwickler Angst haben, Code zu löschen. Die Natur hat keine Versionierung. Die Natur ist wie ein COM Objekt: Bis zu einem gewissen Grad abwärtskompatibel, dann und wann aber auch ziemlich instabil. Bei der Masse an Objekten (nächsten Monat allein ~7 Mrd Menschen) fällt das aber kaum auf.
Das Closed / Open Prinzip
Wenn wir tatsächlich versuchen wollten, so einen Pfad zu beschreiten... was wird dann aus dem OCP? Quasi das O in SOLID? Die Natur ergänzt auch nicht ohne zu verändern. Im Gegenteil: Sie verändert. Weil genau wie Ralf auch richtig anmerkt, das System als Gesamtheit betrachtet wird. OCP setzt auf die Idee, von Anfang an bereits die Möglichkeit noch nicht erdachter Funktionen in Betracht zu ziehen und entsprechende Techniken einzusetzen, um sie tatsächlich mal hinzufügen zu können ohne bereits Existierendes modifizieren zu müssen.
Das steht im Widerspruch zu seinem Hinweis, es auch gedanklich bei dem zu belassen, was hier und jetzt gebraucht wird. Oder sehe ich das falsch?
Fakt ist:
Die (natürliche) Evolution ist in der Lage, ein System im Laufe der (Entwicklungs-) Zeit der (sich stetig ändernden) Umwelt anzupassen. Ob die Zwischenergebnisse oder auch über viele Generationen hinweg vorläufig finalen Ergebnisse dabei besonders effektiv sind oder nicht, sei einmal dahingestellt.
In sofern bin ich nicht sicher, ob es der richtige Weg ist, sich für die Entwicklung von Software die Natur zum Vorbild zu nehmen. Ich habe auch das Gefühl, dass es nicht der richtige Weg ist, Legosteine, Elektronische Bauteile (die Paten standen für die EBC) oder organische Zellen (wie im Falle der Softwarezellen) als Ideengeber zu verwenden.
Da aber in Teilbereichen die Analogien zu existierenden Mustern immer mal wieder hilfreich waren, sollten wir die Möglichkeit in Betracht ziehen, dass es eben nicht Die Eine Programmiersprache gibt oder Das Eine Muster, nach dem Software entwickelt werden sollte... sondern lediglich Lösungswege, die in der Lage sind ein spezifisches Problem in einem spezifischen Kontext zu lösen.
Dieser Kontext ist abhängig von der Zielgruppe, die die Software einsetzt, von den Rahmenparametern die die Entwicklung bestimmen, von den Mitteln, die für die Entwicklung zur Verfügung gestellt werden, den Problemen, die von der Software zu lösen sind, etc.
Denn ehrlich:
Dass heutzutage Software immer weiterentwickelt wird und immer wieder neue Funktionen hinzukommen, ist keine Anforderung aus der Softwareentwicklung heraus. Es ist lediglich ein Konstrukt, dass der Softwareentwicklung aufgezwungen wird, um das Marketing und den Vertrieb rund um ein Produkt künstlich aufrechtzuerhalten und es (dauerhaft) konkurrenzfähig zu machen.
Wie Ralf in einem anderen Artikel bereits beschrieben hat: Warum die (ablaufenden) Lebenszeit eines Produktes nicht von vornherein mit einplanen und auf dem Weg zum Ende dafür sorgen, dass ein neues Produkt das alte ablöst und dabei die gemachten Erfahrungen mit einbezieht.
So schließt sich der Kreis
Denn HIER haben wir imho den einzigen und relevantesten Bezug zur Natur: Die Lebenszeit eines Organismus ist begrenzt. Aufgrund programmierter Triebe (Arterhaltung, etc) ist von der Natur sichergestellt, dass die nächste Generation rechtzeitig auf den Weg gebracht wird, wobei Erfahrungen (Metainformationen, Erziehung) und technische Funktionsweisen (DNS) eine mögliche Verbesserung pro Iteration ermöglich, zumindest aber eine kontinuierliche Anpassung an die Umweltbedingungen stattfinden kann.