Evolvierbare Software. Geschlossen für Erweiterung, Offen für Veränderung?

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.

Comments (2) -

Ralf Westphal
Ralf Westphal
9/5/2011 3:33:15 PM #

Ich finde deinen Hinweis auf das OCP interessant. Wenn ich recht drüber nachdenke, passt es nicht so recht zu meiner Vorstellung von Evolution. Die Natur hält sich keine Hintertür für Erweiterungen auf. Sie verändert, was ist. Falls ein Lebewesen mit Augen, die auch noch im Infrarotbereich sehen können, besser angepasst ist, dann wird das Auge umgebaut. (Das klingt intentional, ist es aber in der Natur natürlich nicht. Es werden vielmehr "Instanzen" selektiert, die dieses Feature implementieren.)

Forsch formuliert könnte man also sagen: Das OCP ist einer Vorstellung von Software geschuldet, die sich zwar irgendwie anpassen soll, aber nicht wahrhaft evolviert.

Wer würde denn auch behaupten wollen, dass SOLID das Ende der Fahnenstange ist. Auch diese Auswahl von Prinzipien hat einen Kontext, der sich ändern kann.

Christian Jacob
Christian Jacob
9/6/2011 8:17:09 AM #

Ganz so sehe ich das nicht.

Aber das hängt im Wesentlichen von der Vorstellung dessen ab, was man unter Evolvierbarkeit versteht. Da dieser Begriff eigentlich ausschließlich aus der Evolutionsbiologie stammt und dort Vorgänge beschreibt, die wir a) so in der Software gar nicht erleben (können) und b) vermutlich auch gar nicht erleben wollen, ist er vielleicht sogar völlig fehl am Platz.

Letzten Endes haben wir ja gerade die Chance, vorauszudenken. In der Softwareentwicklung wissen wir bereits (durch Erfahrungen), dass Anforderungen permanenten Änderungen unterlegen sind. Unsere (Software-) Umwelt ändert sich nicht in Generationen (bzw. Jahrzehnen oder gar Jahrhunderten) sondern in Wochen und Monaten.

Die Fähigkeit, die sich daraus entwickelt hat, nämlich die der "Vorhersehung" und damit Bereitstellung eines technologischen Unterbaus, der das ermöglicht, ohne an den bereits existierenden Grundfesten zu rütteln, ist ein hervorragendes Beispiel einen kleinen aber ungeheuer wichtigen Unterschied zwischen Natur und Technik (hier: der Softwareentwicklung).

Denn Du hast Recht: Die Natur agiert nicht, sie reagiert. Doch während Du das versuchst als einen Vorteil zu verstehen, übersiehst Du etwas Wesentliches:

Die Natur versagt dort, wo sie sich nicht rechtzeitig anpassen kann und beginnt dann immer wieder von vorn. So (in weiten Teilen) geschehen z.B. vor ca. 65 Millionen Jahren. Und sollte ein (von der Natur) unvorhergesehener Vorfall für das Abschmelzen der Polkappen sorgen, wird sie zu spät feststellen, dass es angebracht gewesen wäre, die Menschheit rechtzeitig mit Kiemen auszustatten. Smile

In der Historie der Softwareentwicklung gab es ebenfalls Beispiele für mangelnde Anpassungsfähigkeit.

"[Netscape] did [...] the single worst strategic mistake that any software company can make: They decided to rewrite the code from scratch." (Joel Spolsky, Things you should never do, Part 1, http://bit.ly/nLarxF)

Im Übrigen ist mir klar, dass sich die Argumente damit im Kreis drehen und diese Überlegungen im Widerspruch mit dem Feedback dieses Posts stehen. Vielleicht aber auch nicht, wenn man das Thema in Teilen betrachtet und - genau wie Natur und auch große Firmen es tun - das Beste von allen Seiten nutzt.

Natur und Technologie. Eine Eigenschaftenhelix zusammengesetzt aus den Nukleotiden gemeinsamer Best-Practices.

Comments are closed

Über die Autoren

Christian Jacob ist Leiter des Geschäftsbereiches Softwarearchitektur und -entwicklung und zieht als Trainer im Kontext der .NET Entwicklung sowie ALM-Themen Projekte auf links.

Marcus Jacob fokussiert sich auf die Entwicklung von Office-Addins sowie Windows Phone Apps und gilt bei uns als der Bezwinger von Windows Installer Xml.

Martin Kratsch engagiert sich für das Thema Projektmanagement mit dem Team Foundation Server und bringt mit seinen Java- und iOS-Kenntnissen Farbe in unser ansonsten von .NET geprägtes Team.

Aktuelle Kommentare

Comment RSS