Eigentlich soll ja alles immer besser werden, oder? Die Prozessoren der nächsten Jahre sollen auf die eine oder andere Weise besser sein als die heutigen – so wie die heutigen besser sind als die der 1990er und die wiederum besser als die der 1980er usw. Auch unsere Autos sollen immer besser werden – so wie sie seit mehr 125 Jahren immer besser geworden sind. Das selbe gilt für Fernseher, Mixer und Solarzellen.
Aber nicht nur solch handfeste Dinge sollen besser werden. Auch bei Dienstleistungen mögen wir es, wenn die sich zum Besseren verändern. Wer möchte heute noch einen Gesundheitscheck wie vor 20 oder gar 100 Jahren? Wo wären wir, wenn die Flugabfertigung immer noch wie vor 60 Jahren abliefe? Selbst beim Friseur schätzen wir den Fortschritt.
Dito bei der Arbeitsweise unserer Unternehmen, oder? Und genauso bei der Software. Auch die soll besser werden, vom Betriebssystem bis zum Smartphone Game. Selbstverständlich nehmen wir die Software, die wir selbst entwickeln, da nicht aus.
Ja, das ist eine Welt, wie sie sein soll: alles wird immer besser und besser.
Was ist “besser”?
“Besser” ist dabei ein relativer Begriff in zweierlei Hinsicht. Zum einen steckt in “besser” ein Vergleich zum Bisherigen. Zum anderen gilt “besser” genauso wie das vorgelagerte “gut” nur in einem Kontext, d.h. in Bezug auf eine Umwelt – und darin in Bezug auf einen Wertmaßstab. Es geht mithin um einen Unterschied, der einen Unterschied macht.
Ein Fernseher mit Fernbedienung ist nicht einfach besser als einer ohne Fernbedienung. Aber die Fernbedienung ist schon mal ein Unterschied zwischen beiden.
Doch wenn dieser Unterschied #1 dazu führt, dass Käufer eine andere Entscheidung treffen (Unterschied #2), d.h. die Fernbedienung sie motiviert, den Fernseher mit Fernbedienung zu kaufen statt den ohne Fernbedienung… dann beurteilen wir den Fernseher mit Fernbedienung als besser im Vergleich zu dem ohne.
Der Wertmaßstab ist in diesem Fall zum Beispiel der Umsatz, der mit Fernsehern gemacht wird. Der Fernseher mit Fernbedienung ist besser in Bezug auf den Umsatz – aber vielleicht schlechter in Bezug auf den Kalorienverbrauch der Fernsehzuschauer (Wertmaßstab Gesundheit) oder den Anfall von Elektronikschrott (Wertmaßstab Nachhaltigkeit).
Wenn wir nun in die Welt schauen, dann – so glaube ich – stimmen wir überein, dass vieles über die Zeit tatsächlich besser und besser geworden ist. Der Spruch “Früher war alles besser.” stimmt also nicht pauschal, auch wenn uns der heutige Stand mancher Entwicklung frustriert [1].
Bedingungen für die Möglichkeit zur Verbesserung
Verbesserungen in allen Bereichen unseres Lebens scheinen so natürlich – aber wie kommt es eigentlich dazu? Wie funktioniert diese Evolution unserer Hilfsmittel und Dienstleistungen?
Mir scheint es zwei zentrale Bedingungen dafür zu geben:
- Es müssen überhaupt Ideen für Veränderungen produziert werden. Was könnte der Unterschied #1 zum Ist-Zustand sein? Dafür braucht es ein Milieu, das motiviert, solche Ideen zu produzieren. Sensibilität für Unzufriedenheit, Kreativität, Mut sind nötig.
- Die Ideen für Veränderungen müssen implementiert werden können, um zu sehen, ob es zu einem positiven Unterschied #2 in Bezug auf einen für Produzenten wie Konsumenten relevanten Wertmaßstab kommt.
Die Natur als Beispiel
Die Natur macht uns das sehr schön seit Milliarden von Jahren vor. Sie erfüllt beide Bedingungen: die erste durch genetische wie epigenetische Veränderungen, die zweite durch Reproduktion.
Krankheit und Tod zeigen auf, wo Lebewesen noch nicht zufriedenstellend an die Umwelt angepasst sind. Mutationen sind äußerst kreative Veränderungen – oft jenseits unseres Vorstellungsvermögens; wir hätten es nicht besser machen können. Und Mut hat die Natur genügend, da sie durch keine Glaubenssätze beschränkt ist.
So werden Lebewesen von Generation zu Generation besser und besser bzw. erhalten sich die Güte ihrer Überlebensfähigkeit.
Der Markt als Beispiel
Auch der Markt macht uns vor, wie die Bedingungen erfüllt werden können. Konkurrierende Anbieter generieren kontinuierlich Ideen für Veränderungen, die sie über neue Modelle an den Markt bringen.
Vor allem im Bereich des Materiellen funktioniert der Markt damit wie die Natur. Besser wird es durch Generationen von Modellen. Ein Fernseher hat eine Lebensdauer, ebenso ein Flugzeug und ein Röntgengerät. Spätestens nach dieser Lebensdauer kann es durch etwas Besseres ersetzt werden.
Tod als Herz der Evolution
Natur und Markt gleichen sich. In ihnen schlägt das selbe Herz der Evolution: der Tod. Das in der Vergangenheit Gute macht durch seinen Tod ganz automatisch Platz für das inzwischen besser gewordene.
Das Ganze - die Summe aller Lebewesen, d.h. das Ökosystem, bzw. die Summe aller Modelle, d.h. der Markt – erhält seine eigene übergeordnete Lebensfähigkeit also dadurch, dass seine Teile in einem ständigen Prozess von Werden und Sterben stehen.
Allemal gilt das für seine kleinsten Teile, aber durchaus für Subsysteme größerer Granularität. Die Lebensdauer bzw. die Dauer des Verbleibs im System wächst dabei tendenziell mit der Größe eines Subsystems.
Perverse Unsterblichkeit
Lebewesen sterben. Das gehört zu ihrer Definition. Misslich ist es für uns Menschen, dass wir von unserer Sterblichkeit wissen. Sie macht uns nur allzu oft Angst. Da helfen alle Maßnahmen der Gesundheitsvorsorge und Reparaturmedizin auch nicht. Nach rund 100 Jahren machen wir Platz für die Nachgeborenen.
Materielle Produkte haben auch nur eine überschaubare “Lebenserwartung”. Selbst bei bester Pflege fordern Physik (z.B. durch Reibung oder thermische Kräfte) oder Chemie (z.B. durch Oxidation) früher oder später ihren Tribut. Und wo das dem Hersteller zu lange dauert, da setzt er auf planned obsolescence.
Aber wie ist es bei Unternehmen? Wie ist es bei Software?
Bei immateriellen Hilfsmitteln [2] herrscht ein anderes Ideal: sie sollen unbegrenzt lange existieren. Niemand gründet ein Unternehmen mit einer Idee von dessen Lebenserwartung [3]. Und niemand schreibt Software mit einem Verfallsdatum [4].
Ist das nicht pervers, d.h. anormal, verkehrt, unnatürlich – für etwas, das ständig besser werden soll?
Markt und Natur, also die umfassenden Systeme, sollen nicht besser werden, sondern beherbergen das, was immer besser werden soll, um sich als Ganzes zu erhalten [5]. Die umfassenden Systeme kennen keinen auf gleicher Ebene existierenden Konsumenten. Es sind autopoietische Systeme, sie erhalten sich selbst. Wenn sie dienen, dann eher nach innen, ihren Konstituenten gegenüber.
Für mich sieht es so aus, als würden wir Unternehmen sowie Software heute in einem Widerspruch herstellen bzw. betreiben:
Wir strukturieren sie einerseits wie materielle Produktmodelle, d.h. vergleichsweise starr. Das haben wir ja auch über Jahrhunderte gelernt. Sie erfüllen zu einem Zeitpunkt einen Zweck, sind temporär also gut. Eine Verbesserung können wir erst mit einem neuen Modell erwarten.
Andererseits denken wir sie unsterblich, d.h. als übermaterielles System, das es durch ständige Veränderung im Inneren zu erhalten gilt.
Ja, was denn nun? Innen starres Hilfsmittel, das über Generationen evolviert – oder innen flexibles System mit unbegrenzter Lebenserwartung?
Da passt doch irgendetwas nicht, oder?
Hinderlicher Erfolg des Immateriellen
Die Quelle für diesen Widerspruch sehe ich in einer scheinbaren Wahl, die wir haben. Immaterielles wie ein Unternehmen oder Software unterliegt keinem natürlichen Verfall – also können wir die Lebenserwartung selbst bestimmen. Und da bestimmen wir mal, dass die unendlich sein soll. Geht doch. Und ist bestimmt unterm Strich billiger, als immer wieder etwas Neues von Grund auf herzustellen, oder?
Dass sowohl Unternehmen wie Software dann doch nicht ewig existieren, ist eine andere Sache. Shit happens. Potenziell könnten sie es jedoch. Darum gilt es, das anzustreben.
Der Erfolg zu einem bestimmten Zeitpunkt scheint in die Zukunft verlängerbar. Ein Auto funktioniert ja auch mit guter Wartung nicht nur heute, sondern auch noch in Jahrzehnten.
In Wirklichkeit steckt hier jedoch das Missverständnis. Erfolgreich heute – also in Bezug auf heutige Umwelt und Wertmaßstäbe gute Systeme – bedeutet nicht, erfolgreich morgen.
Umwelt und Wertmaßstäbe für Unternehmen und Software sind solchem Wandel unterworfen, dass in ihnen ständig umgebaut werden muss. Ein treffendes Bild scheint mir das einer stehenden Welle: die äußere Form bleibt trotz allem Fluss im Inneren erhalten.
Solange Erfolg mit einem Ist-Zustand an Strukturelementen und Beziehungen gleichgesetzt wird, funktioniert das aber nicht. Erfolg muss davon abgekoppelt werden. Welche Konstituenten ein System ausmachen, ist für die langfristige Existenz des Systems als Ganzem unwichtig. Es gibt nichts per se Erhaltenswertes. Es gibt immer nur einen Systemaufbau, der angesichts einer Umwelt und eines Wertmaßstabs gut genug ist – und sich leicht an Veränderungen anpassen lässt.
Anpassungsfähigkeit ist die einzige erhaltenswerte Eigenschaft. Alles andere steht ständig zur Disposition. Es gibt kein einfach so extrapolierbares Erfolgsrezept im Konkreten, sondern um im Abstrakten.
Praktische Konsequenz
Vielleicht sind unsterbliche Unternehmen und Softwareprodukte wünschenswert. Derzeit sehe ich jedoch nur Versuche zu solcher Unsterblichkeit unter zunehmenden Schmerzen. Wir wissen einfach nicht so richtig, wie wir Unsterbliches aufbauen müssen. Oder wenn wir es wissen, dann setzen wir dieses Wissen nicht systematisch um.
Was also tun? Wir müssen raus aus dem Widerspruch.
Die Blaue Pille nehmen würde bedeuten, bei den aktuellen Konstruktionsweisen zu bleiben. Dann sollten wir aber zumindest die Lebenserwartung von Unternehmen und Software von vornherein begrenzen. “Wir gründen unseren online Shop mit einer Lebenserwartung von 8-12 Jahren.”, “Wir legen die Software auf eine Nutzungsdauer von 3-5 Jahren aus.” – und danach ist Schluss. Ende. Tot. Unternehmen und Software werden dann ersetzt.
Da diese Endlichkeit allen von Anfang an klar ist, kann vorgesorgt werden. Ableger können rechtzeitig gezeugt werden, die neue Erkenntnisse umsetzen – wozu das schon länger Existierende nicht wirklich fähig ist. Die Ausgründung, die Neuentwicklung sind dann keine Überraschungen, sondern ganz natürlich.
Erfolg heute wäre dann kein Ballast mehr für das Bessere. Erfolg wäre nicht narzistisch, sondern bescheiden.
Die Rote Pille nehmen würde hingegen bedeuten, die aktuelle Konstruktionsweise umzukrempeln. Das scheint mir schwieriger – aber nicht unmöglich. Wir müssten lernen, Unternehmen und Software intern eher so zu strukturieren wie ein Ökosystem. Das würde bedeuten, ihre Konstituenten würden evolvieren wie der Automarkt oder die Arten auf einer einsamen Insel.
Hier würde Erfolg per definitionem nicht dem Besserem im Wege stehen. Anpassung wäre in die Systeme eingebaut.
Blaue Pille oder Rote Pille – oder ein Pillencocktail? Ich weiß nicht. Nur sollte es nicht so weitergehen wie bisher. “Aber wir haben doch die letzten 5 Jahren tolle Umsätze gemacht, wir hatten Erfolg… Warum sollten wir jetzt etwas verändern?” darf kein Argument mehr sein, mit dem Veränderungen geblockt werden.
Wir müssen die Bedingungen für die Evolution herstellen: Ideen müssen nicht nur her, sondern auch in bunter Vielfalt implementierbar sein. Evolution ist verschwenderisch. Ressourcenverbrauch auf momentane Bedürfnisse hin zu optimieren, steht längerfristigem Überleben im Wege.
Der wahre Feind der Verbesserung lauert also ständig schon im eigenen System: es ist der heutige Erfolg. Diese Situation müssen wir systematisch bekämpfen.
Fußnoten
[1] Warum wird der Spruch dennoch immer wieder geäußert. Je älter Menschen werden, desto eher scheinen sie ihn auszusprechen. Ich denke, das liegt daran, dass es mit dem Alter erstens überhaupt möglich wird, einen Vergleich zwischen früher und heute anzustellen. Und zweitens hat der Spruch weniger mit den Eigenschaften eines Gegenstandes oder einer Dienstleistung zu tun, als vielmehr mit dem Wertmaßstab.
Es kann sein, dass der vergleichsweise unverändert ist; er hat sich nicht auf die Co-Evolution von Angeboten und Umwelt eingelassen.
Oder es kann sein, dass er sich einfach nur in eine andere Richtung entwickelt hat. Mit zunehmendem Alter verschieben sich Bedürfnisse eben.
[2] Unternehmen subsummiere ich hier mal unter dem Begriff Hilfsmittel. Gegenüber seinen Kunden, ist ein Unternehmen natürlich kein Hilfsmittel, sondern produziert welche. Aber Eigentümer und Angestellte sehen Unternehmen natürlich als Hilfsmittel zur Existenzsicherung.
[3] Ausnahmen gibt es natürlich: Filmproduktionsfirmen haben u.U. eine bewusst auf die Herstellungsphase begrenzte Lebensdauer. Auch Fonds können so organisiert sein, dass ihre Firma nur für die Laufzeit existiert. Oder “Blasenfirmen”, die nur solange irgendwie lebensfähig und vor allem vielversprechend sein müssen, bis sie jemand kauft.
[4] Von Software, die durch absehbare Gesetzesänderungen nur begrenzt relavant ist, sehe ich einmal ab. Meist betreffen solche Termine der Umwelt ja auch nur Teile einer Software.
[5] Erhaltung kann natürlich auch als eine Form der Verbesserung angesehen werden – aber auf einer höheren Ebene. Wenn die Natur heute aber anders aussieht als vor 100 Millionen Jahren, für wen macht das einen Unterschied #2?
19 Kommentare:
Ich mag Deine Idee, Software in der Welt von Leben und Tod einzuordnen. Ich bin aber nicht so sicher, ob ich Software genauso einordnen würde wie Autos.
Für mich ist Software eher wie Literatur. Nur viel dynamischer. Und welchen Lebenszyklus hat Literatur? Wochen bis Jahrtausende (und immernoch "lebendig"). Die Charakteristik von Literatur oder Software ist für mich weniger die eines Lebewesens, sondern viel eher vergleichbar mit DNA, der Grundlage von Leben. Genauso wie mit Hilfe von DNA irgendwelche Proteine produziert werden, die sich auf irgendeine Art und Weise zu Strukturen zusammenfinden oder Prozesse anstoßen, wie DNA kopiert wird, mutiert und so langsam mit der Zeit andere Ergebnisse, anderes Leben hervorbringt, genauso funktionieren für mich Literatur und Software.
Literatur inspiriert, leitet an, unterhält, dokumentiert. Und sie wird immer wieder kopiert (und ich meine nicht den Buchdruck sondern 'abschreiben') und dabei verändert, meist viel schneller als DNA. Der Grad von öffentlicher Verfügbarkeit von Literatur befeuert die Anzahl an neuer Literatur und ihre Vielfalt.
Software installiert andere Software, Software läuft irgendwo und bietet Dienstleistungen an, Software unterhält. Software wird vervielfältigt (und ich meine nicht die Softwareinstallation sondern den Source Code) und Software verändert sich ständig. Meist viel schneller als Literatur. Und der Grad von öffentlicher Verfügbarkeit von Software in Form von Source Code (Github, Open Source Frameworks) lässt die Zahl und Vielfalt von Software explodieren.
Wenn man nun die drei miteinander vergleicht, dann könnten interessante Kriterien z.B. sein: Die Änderungsrate, die erschaffbare Komplexität, die Robustheit (und folglich die Überlebensfähigkeit nach Änderungen), die Zukunftsfähigkeit (bringt diese DNA auch morgen noch Lebewesen hervor, die überlebensfähig sind).
Ich weiß nicht, ob ich mich nach Deinem Modell jetzt für die rote Pille entschieden habe. Aber ich würde Software trotzdem nicht als Ökosystem betrachten, allenfalls die Softwareinstallation, was aber nur eine Inkarnation des Source Code ist. Und der ist eine Bauanleitung, nicht mehr. Eine Anleitung, die sich verändern kann (und soll), eine Anleitung die in andere Umgebungen (Ökosysteme) portiert wird, eine Anleitung, die Grundlage für andere Anleitungen ist.
Die Fragen die sich nach der Betrachtung dieser Kriterien ergeben, gehen eher in die Richtung: Wie sollte eine DNA für Softwareinstallationen gebaut sein, damit sie den Kriterien am besten genügt? Wie sollte diese DNA am besten ausgelesen werden (kompiliert/interpretiert)?
Etc. etc. ... genug Stoff zum Weiterdenken.
Danke für die Inspiration :-)
@pvblivs: Software als DNA... das klingt interessant - aber ich weiß noch nicht, was ich damit wirklich anfangen kann. Werde mal grübeln...
Einstweilen zur Erklärung meines Standpunktes:
Bei Auto, Haarschnitt, Unternehmen und Software haben wir es mit Werken zu tun. D.h. das ist "etwas", das intentional entstanden ist.
Insofern gehen Werke über Dinge hinaus. Dinge sind Unterscheidbares in der Welt: Blatt, Stein, DNA sind auch Dinge - aber keine Werke. (Zumindest solange man nicht Anhänger von Intelligent Design ist ;-)
Und ich gehe noch weiter: Diese Werke sind sogar Zeug, d.h. sie sollen einen konkreten Nutzen erfüllen. Durch ein Zeug wird die Menschheit in zwei Gruppen geteilt: Produzenten und Konsumenten.
Der eine stellt das Zeug her, der andere nutzt das Zeug. (Manchmal sind Produzent und Konsument auch dieselben. Macht aber nix.)
Zeug existiert also nicht aus sich heraus und für sich, sondern in Bedingtheit. Es wird bedingt durch Produzent und Konsument. Das essenziell Dingliche an Zeug, seine Beschaffenheit, seine Merkmale, wird auf einen Zweck hin bestimmt von außen. Zeug ist somit Objekt von Subjekten.
Und damit wird es schwierig. Denn den Horizont der Subjekte ist immer begrenzt. Er schrumpft sogar stetig. Produzenten und Konsumenten können nicht mehr abschätzen, wie Zeug in 100, 50, 10, 5 Jahren beschaffen sein sollte.
Damit ändert sich die Qualität der Ökonomie der Zeugherstellung, würde ich sagen. Und das hat zur Folge, dass Zeug bei gleichem Zweck anders aufgebaut sein sollte.
Der ultimativ geschrumpfte Horizon hat den Radius 0. Das bedeutet: keine Ahnung, was morgen ist. Darauf bewegen wir uns zu. (Naja, nicht ganz, aber ein bisschen plakativ darf es hier sein ;-) Diesen Horizont hat die Natur. Sie macht keine Annahmen.
Aber Natur ist ja nicht Starre. Wie kommt es, dass da Leben ist? Leben ist nur Ding, kein Werk, kein Zeug. Leben macht einfach. Und Leben ist leidenschaftslos. (Oder vielleicht klingt es besser, wenn ich sage, die Natur ist leidenschaftslos?)
Werden und Sterben passieren. Die Natur hängt an keinem Exemplar (sozusagen Instanz) und keiner Art (sozusagen Klasse).
Und so hat sich ein, hm, Gleichgewicht eingestellt zwischen Horizontweite und Aufbau lebender Dinge. Das funktioniert augenscheinlich wunderbar.
Dahin müssen wir auch kommen. Unser Horizont schrumpft und die Baumaterialien für Zeug ändern sich. Da müssen wir rauskommen aus dem Denken von vor 50 und 500 Jahren.
Software und Unternehmen sind in mehrerlei Hinsicht keine Katedrahlen. Aber wir bauen sie noch so.
Unternehmen und Software sind eher wie Lebewesen - obwohl sie Zeug sind. Na, dann sollten wir uns mehr von der Natur abschauen, denke ich. Dazu gehört zum Beispiel die begrenzte Lebensdauer.
Deine Intention war mir nicht so klar. Es stimmt, dass Software nicht so gebaut werden sollte "wie Kathedralen". Software (oder besser Source Code) ist ja virtuell. So wie Unternehmen (oder eher, treffender die Organisation). Virtualität bedingt, etwas ist prinzipiell hoch volatil/veränderbar. Stimmt das? Man könnte darüber sinnieren, ob es ein evolutionärer Nachteil ist, wenn es keine intrinsischen Beschränkungen für Veränderung gibt, man aber trotzdem nicht veränderungsfähig ist (weil man z.B. zu spezialisiert ist). Potentiell verändern sich ja andere von der selben volatilen Natur schneller. Und damit gibt es mehr erfolgreiche evolutionäre Experimente. Statistisch gesehen wird man selbst also verlieren. Das klingt für mich aber eher nach Evolution von Dingen (die zufällig auch Zeug sind) als nach Planung der Lebensdauer von Zeug.
Ein Beispiel: NSObject. Die Firma NEXT und das NEXTStep UNIX gibt es nicht mehr. Der Gründer ist tot. Aber grundlegende DNA-Schnipsel dieser Firma wie NSObject sind heute Grundlage für eines der erfolgreichsten Softwareökosysteme auf modernen mobilen Produkten. Auf vielen Geräten, die wir heute verwenden, findet man genau dieses 'Erbgut'. Anderes Beispiel sind die Softwareökosysteme der Microsoft-Plattform. Auch diese Schnittstellen sind grundlegende Bausteine für alles Leben, konkrete Software, auf eben einer anderen Plattform. Die viel verfluchte Abwärtskompatibilität ist auch ein Zeichen für den immernoch anhaltenden Erfolg.
Wenn man Source-Code wie DNA denkt und Software wie das resultierende Leben, dann wäre eine DNA-Mutation ein Experiment, deren Erfolg sich daran misst, wie erfolgreich die konkrete Software dann "lebt". Wie in der biologischen Evolution gibt es Mutationen die zum sofortigen oder frühen oder baldigen Aussterben führen, es gibt evolutionäre Sackgassen und es gibt erfolgreiche, anpassungsfähige Stränge.
Die meisten Software-Experimente geht morgen gleich wieder unter. Sie setzt sich nicht durch. Sie ist nicht erfolgreich beim Kunden (wichtigstes Kriterium, würde ich sagen), sie ist schlecht testbar, sie hat einen hohen Grad von fatalen Kopplungen, sie ist nicht mehr änderbar, z.B. weil sie keiner versteht, kurzum sie stirbt bald aus.
Andere Software-Experimente sind mittelmäßig erfolgreich. Sie haben zum Beispiel lange Bestand, sind aber hochspezialisiert an ihre Umwelt, ideal für ihren heutigen Erfolg, aber vielleicht eine evolutionäre Sackgasse (was auch immer die Kriterien dafür sind). Der Vendor-Lock-In als evolutionäre Sackgasse der proprietären Vendor-DNA ;-)
Zuletzt gibt es Software, die man immer wieder trifft. Netscape -> Mozilla -> Firefox. KHTML/KJS -> Safari (Webkit) -> Chrome. Unix -> Linux, Mac OS, iOS, Android etc, etc. etc. Die konkrete Software oder ihre Firmen sind zum Teil untergegangen, aber die DNA hat sich durchgesetzt. Das würde ich als evolutionär extrem erfolgreich beurteilen. Und die erfolgreichen Experimente sind nun Blaupausen für uns, wie man eigentlich Software entwickeln muss, wenn man den evolutionären Erfolg von Software als Ziel hat.
Das wäre für mich die Frage, die man abstrakt stellen könnte: Warum überlebt eigentlich Source Code?
Im Grunde ein Plädoyer für OpenSource. Und für die Prinzipien für gute Programmierung.
Lebensdauer von Software kann man schlecht planen. Man kann aber an der Software-DNA, dem Source-Code planen: Dass Fehler in der DNA schmerzlos sind, der Tod von DNA-Schnipseln nicht der ganzen DNA die Überlebensfähigkeit nimmt. Dass erfolgreiche DNA nicht in eine Sackgasse gerät, d.h. nicht mehr mutierbar ist ohne zum Aussterben zu führen. Dass erfolgreiche DNA die Grundlage für mehr Mutionen, Experimente und dafür noch mehr erfolgreiche DNA ist.
Hallo,
ich kann eure Gedanken schlecht folgen: worauf zielt ihr ab? Das Software nur begrenzte Lebenszeit hat? Und dann?
Sollen wir möglichst "schnell" entwickeln? Nachhaltig, langlebig = Unsinn?
Mir wären konkrete Szenarien, Gedankengänge lieber, als die blumigen Formulierungen. Ansonsten fällt es schwer zu folgen, mag so sein oder auch nicht.
Also Ralf muss für sich selbst eine prägnante Antwort geben.
Ich versuche mal zu erklären, welches Problem ich lösen 'will':
Entwicklung von Software ist relativ leicht. Nachhaltige Softwareentwicklung ist schwer. Seit Softwareentwicklung eine Commodity geworden ist (d.h. seit es so einfach ist dass jeder das macht), entsteht viel Software, die morgen schon nicht mehr überlebensfähig ist - auf Grund irgendwelcher Defizite. Ich sage bewusst irgendwelche, weil es handwerkliche, Business- oder Verständnisprobleme gibt - und ich glaube es macht wenig Sinn sie voneinander zu trennen, weil das eine meist zum anderen führt.
Nun gibt es ein paar Hände voll Hilfsmittel (Prinzipien, Patterns, Clean Code, Clean Architecture, Flow-orientierte Programmierung, MDA, DDD, TDD, CI, CD und CLD etc. etc. etc.) die jeweils dabei unterstützen wollen, Softwareentwicklung nachhaltiger zu machen. Und das funktioniert auch alles in einem begrenzten Umfeld. Es ist aber noch nicht 'der heilige Gral'.
TDD z.B. ist eine Mikrooptimierung des 'WIEs' der Softwareentwicklung. Meine Beobachtung hier ist ähnlich der von Ralf. Wobei ich stärker auf den Sinn abfahre. Tests haben für mich einen spezifischeren Zweck - und die dürfen unter Umständen auch manuell sein.
M.E. gibt es viel größere Probleme. Die liegen meist auf der Makro-Ebene der Software: Das Gesamtverständnis der Software, die Testbarkeit des Gesamtsystems oder des Subsystems, die unterschiedlichen Niveaus der Kontributoren und die daraus resultierende Inkonsistent, das oftmals trotz aller guter Prinzipien gigantisch komplexen Designs, die hohen Kopplungsgrade.
Meine derzeitige Vermutung ist, dass der Schlüssel darin liegt, viel schneller viel generischer zu werden. D.h. im Grunde das jedes Stück Software ein Tool ist, ein kleines Framework. Diese Tools sollten aber so gebaut werden, dass sie so wenig Abhängigkeiten wie möglich haben, d.h. dass ein unbenutztes Tool einfach entfernbar ist. Und dass die eigentliche Applikationslogik nur noch eine Kleinigkeit ist.
Das hilft mir nicht bei der Lösung eines kurzfristigen Business-Problems - viele Entwickler wehren sich gegen solches Vorgehen (Technologie auf Vorrat). Beeinflusst aber die mittelfristige Entwicklungsgeschwindigkeit und langfristige Wartbarkeit der Software ganz enorm.
Dieses Philosophieren, blumige Formulieren dient eigentlich für mich dazu, zu verstehen, was eigentlich Ziele von Softwareentwicklung auf der Meta-Ebene sein sollten. D.h. wenn Softwareentwicklung nachhaltig oder schnell sein soll, was bedeutet das? Und was ist das Wesen der Nachhaltigkeit oder Geschwindigkeit, wie kann man sie begreifbar machen?
Und in Bezug auf die DNA-Diskussion, mit der ich ja die Diskussion Ding vs. Zeug gehijacked habe, fahre ich eher darauf ab zu sagen: Es gibt immer ganz schnell wieder toten Code. Es gibt Code der wieder ausgebaut werden soll. Es gibt Code der ersetzt worden ist aber aus Kompatibilitätsgründen noch anwesend. Es gibt aber auch mittelmäßig oder sogar extrem erfolgreichen Code. Und das alles in einer Code-Basis.
Wie muss man nun Software entwickeln, dass das alles kein so großes Problem ist? Wie muss man Software entwickeln, dass der eine erfolgreiche Code den anderen nicht behindert? Wie stellt man sicher, dass erfolgreicher Code erfolglosen Code nicht unnötig am gehen hindert (z.B. wegen hoher Verzahnung). Ja: Wie kann man Software trotz all dieser Variablen schnell herauspumpen - und zwar langfristig auf der gleichen Codebasis?
Und dabei an der Lösung zu arbeiten hilft es, Analogien zu finden. Was ist eigentlich Software? Jedes Problem ist ja schonmal gelöst worden - nur in einem anderen Kontext :-)
Hallo pvblivs,
jetzt ist es etwas klarer. Ich denke auch, Analogiebildung hilft dabei, um soetwas Abstraktes wie Software verständlich, greifbarer zu machen.
Nun ist es aber so, dass mit jeder Analogie nur ein Teil der "Wahrheit" formuliert werden kann.
>Entwicklung von Software ist relativ leicht...
Hmm, da habe ich Zweifel. Jeder kann ein Programm (Folge von Anweisungen) erstellen, so wie jeder Hammer und Nagel benutzen kann. Nur die Erstellung eines Programms macht keinen professionellen SW-Entwicker (also jemanden der dauerhaft mit dieser Tätigkeit seine Famlien ernähren kann); und ebenso macht die erfolgreiche Benutzung von Hammer und Nagel noch keinen Zimmermann. Es mag sein, dass man durch dauerhafte Ausübung dieser Tätigkeit(en) die Disziplin erlernt und das "Handwerk beherrscht", aber in D gibt es Handwerkskammern, die sorgsam darauf achten, dass kein Wildwuchs entsteht. Ob das gut oder schlecht ist, mag ist nicht beurteilen, aber es gibt keine Kammer für SW-Entwicklung und nur weil man ein Programm schreiben kann, sollte man nicht daraus folgern, dass man es auch professionell machen könnte.
In den 60ern, 70ern wurde Software von der Methodik anders entwickelt, als zu den 80ern und 90ern. Nur weil in diesen Jahren jedermann Software erstellen konnte (weil PCs erschwinglich waren, C64-Zeiten blende ich einmal aus), wurde soviel (und leider auch viel Mist) produziert. Zur Jahrtausendwende platzte die Dot-Com-Blase. Was, wie bedingt hat, was die Ursachen waren, weiss ich nicht.
Ich habe den Eindruck, dass seit dieser Zeit, die Entwicklung und Profession wesentlich besser geworden sind und "Hilfmittel" (TDD, ...) und Methodiken entstanden sind, die alles einen Schritt nach vorn gebracht haben.
Zu Generisch, wiederverwendbar, langlebig, YAGNY, KISS, etc:
Wenn man genug Software geschrieben, entworfen, gelesen, diskutiert, weggeworfen und benutzt hat, dann bringt man immer etwas mit - man beginnt nicht bei Null. Letztlich denke ich, es ist ein Konflikt aus dem eigenen Anspruch und dem was der Kunden bereit ist zu zahlen.
Ansonsten fällt mir auf, dass viel zu viele IT-ler sich einbilden zu verstehen, wie das Geschäft, der Markt funktioniert und Ad-Hoc eine passende Lösung aus dem Hut zaubern können. Man kann recht schnell einen Entwurf skizzieren, aber ob der Entwurf, das Modell passend ist, das benötigt Zeit und kostet Energie (man muss ganz viel zuhören, reden, verstehen und anpassen, reden, zuhören...). Mir ist es ab und zu zu oberflächlich und daher zu schnell: Effizienz vs. Effektivität.
Wem nützt 100% testabgedeckte Software, die qualitativ hochwertig ist, aber schlichtweg nicht den vollends hilft?
> Zu Kopplungsgrade
Ja, der Entwurf von Software scheint immer noch ein Problemkind zu sein.
Teile-und-Herrsche, Module und Schnittstellen und Möglichkeiten zur Abhängigkeitsumkehr scheinen immer noch nicht zum Handwerkzeug zu gehören.
Ich glaube, wir brauchen noch drei Begriffe für diese Diskussion: Lösung und Implementation und Meme.
Was du mit DNA gemeint hast, verstehe ich nun besser, denke ich. Da kann ich etwas mit anfangen: da steckt etwas in Software, das zu Neuem führt.
Aber ich würde sagen, das ist nicht die Software. (Von Copy&Paste oder auch Komponenten sehe ich mal ab.)
Was da drin steckt, das ist ein Meme, also etwas Immtaerielles. Und das ist auch nicht Teil der Software. Software - also der Code, der auf deinem Rechner läuft genauso wie der Quellcode - ist eine Implementation einer Lösung.
Quicksort ist eine allgemeine Lösung für ein Sortierproblem. Quicksort geschrieben in C# ist eine Implementation dieser Lösung für eine Plattform und womöglich sogar einen Datentyp.
In Quicksort gibt es dann Meme, zum Beispiel "Teile und Herrsche" oder "Rekursion".
Meme stecken in Materiellem und Immateriellem, würd ich sagen. Die pflanzen sich fort - wenn sie attraktiv genug sind. Aber dann natürlich nur in Werken, denn wir Menschen sind ihre Überträger.
Aber jetzt nochmal zum Ausgangspunkt:
Mir gehts darum, dass Konsumenten Lösungen haben. Die können in Gegenständen, Dienstleistungen oder in Software bestehen. Das sind unterschiedliche Implementationsformen.
Die Frage ist nun: Wie kriegen wir es hin, dass Lösungen immer dicht an den in Bewegung befindlichen Anforderungen der Konsumenten sind?
In der materiellen Welt geht das über Modelle. Anforderung (oder gar Bedürfnis): Mobilität.
Lösung: Auto.
Implementation: Ford T oder VW Käfer oder Audi A8 :-)
(Es kann natürlich noch andere Lösungen geben, z.B. Zug, Flugzeug, Fahrrad mit jeweils eigenen Implementationen wie ICE oder A380.)
In der Softwarewelt versuchen wir es nun anders. Und auch in der Unternehmenswelt.
Die Anforderung mag lauten: Texte schreiben.
Die Lösung ist: Textprozessor
Die Implementation: Word oder Notepad
Schon während ich das schreibe, merke ich, dass hier Lösung und Implementation ganz dich zusammenrücken (wollen).
Und genau das scheint mir das Problem. Damit erstarrt die Implementation, weil sie zur Lösung wird. Denn die Lösung ist viel weniger variabel.
Mir geht es also darum, erstens Lösung und Implementation deutlich zu trennen. Und zweitens dann Implementationen so zu bauen, dass die lange attraktive Lösungen darstellen.
Bei Autos ist das kein Problem. Die verfallen. Also entwerfen wir neue Modelle und bauen neue Implementationen.
Bei Software jedoch... da ist das anders. Implementationen verfallen nicht. Wir entziehen uns damit die uralte Grundlage der Evolution.
Gut, dann entwerfen wir die Schmittstelle Auto (für den Anwendungsfall) und implementieren Ford T.
"Lösung" = Schnittstelle
"Implementation" = Implementierung der Schnittstelle.
Wenn irgendwann Ford T nicht mehr reicht, entsteht Ford T II oder Audi A8.
Grundlage sind Schnittstellen und Implementierung und Nutzung dergleichen. Daneben versucht man noch die Abhängigkeiten zu minimieren und einiges per Konfiguration(sschnittstelle) in die Implementierung reinzuparametrieren, um keine keine starre Ausprägung zu haben. Aber vielleicht es auch die Implementierung auch wieder nur eine Menge aus kleineren Einheiten.
Ne, das klingt für mich nicht richtig. Eine Schnittstelle entspricht nicht einer Lösung.
Eine Lösung kann eine Schnittstelle haben, aber sie ist keine.
Ist mir auch zu technisch gedacht. Da ist Lösung schon zu eng. Dann muss es womöglich schon Software sein als Implementation.
Menschen wollen aber keine Software, sondern Implementationen von Lösungen - irgendwie. Wenn das vorgestern mit Bediensteten ging, gestern mit einem Gerät, heute mit Software... was dann morgen passt, weiß man nicht.
Vielleicht besteht morgen die Lösung oder die Implementation darin, dass eine Regelung abgeschafft wird?
Wenn wir innerhalb von (Software-)Implementationen mit Schnittstellen arbeiten, dann mag das zu deren Evolvierbarkeit aber natürlich beitragen.
Okay, Schnittstelle = Lösung ist nicht korrekt; eine Schnittstelle ist der Vertrag zwischen zwei Partnern.
Gehen wir zurück zu den Lösungen und noch weiter zurück zu den Features, den Anforderungen und noch weiter zu den Problemen, Prozessen oder Zwängen.
Die Software altert also nicht (im Sinne mechanischer Alterung = Verschleiss), vielmehr erweist sich die aktuelle Lösung im Kleinen (in Komponenten oder Schnittstellen) oder auch im Grossen (IT-Landschaften) mit der Zeit als überholt. Diese Erkenntniss kann aus Kundensicht (weil sich die Anforderungen, Constraints oder Kontext ändern) oder von Innen heraus (neue Sprachen, Bibliotheken, Konzepte, Architekturansätze, ...) vielleicht erklärt man gewisse Teile auch einfach als Legacy oder "nicht schick" oder "nicht mehr zeitgemäß").
D.h. nicht die Software altert, sondern die Anforderungen altern und bewegen sich und die zugehörige Software muss angemessen und dazu sein (und da sind wir wieder bei deinem Artikel).
Erneuerung und (Produkt)Lebenszyklus, Break-Even, Gewinnabschöpfung, Kosten/Nutzen, Risiken und Investitionen sind die Herausforderungen eines Unternehmens im Markt, gleiches gilt für dessen Produkte, Projekte, Diensleistungen oder Prozesse - alles was dem Zweck und Ziel der Unternehmung dient.
Die allgemeine Betrachtung dieser Zusammenhänge ist sicherlich spannend, aber interessanter finde ich die Herausforderungen in Software.
Ja, Software altert nicht im üblichen Sinne. Der ist nämlich: Existierende Strukturen erfüllen immer weniger die Anforderungen, obwohl die sich eigentlich nicht verändert haben. Die Strukturen verfallen, weil die sie konstituierenden Materialien verschleißen.
Deshalb gibt es auch keine Reparatur und Wartung für Software.
Bei Software ist es vielmehr so: Unverschleißbare Strukturen hinken sich ändernden Anforderungen immer weiter hinterher.
Also müssen die Strukturen verändert werden, um den Nutzen von Software zu erhalten.
Bei materiellen Zeugen ist also entweder die Lebensdauer kleiner als die Anforderungsdauer. (Die Umwelt ist länger konstant als das Zeug funktionstüchtig ist.) Oder die Anforderungen ändern sich - und die Strukturen können nicht nachgeführt werden.
Das ist sogar nicht nur bei Zeug so, sondern auch bei Lebewesen. Deshalb haben wir eine florierende Evolution.
Bei Software ist das gaaanz anders. Deren Lebensdauer ist unbegrenzt, d.h. Anforderungen ändern sich immer (massiv) währenddessen.
Deshalb (!) muss Software ganz anders gebaut werden. Ganz, ganz anders. Geradezu einzigartig. Und damit haben wir keine Erfahrung.
Oder: Wenn wir halt nicht so recht wissen, wie man sie dafür baut, dann lassen wir es halt - und führen eine künstliche Lebensdauer ein.
Das scheint mir derzeit der naheliegende Weg - und womöglich ist es sogar der am Ende immer noch richtige.
Rewrite statt refactor. Davon werde ich immer mehr ein Freund.
Hmm ... jetzt bin ich verwirrt. Was ist denn nun Dein Thema? Das Verschwimmen physischer und virtueller Welten? Die erstmal abstrakte Forderung nach der Trennung von Lösung und Implementierung? Oder Rewrite vs. Refactor?
Weil der letzte Kommentar jetzt erstmal gilt: Du argumentierst also, dass man Software passgenauer schreiben kann, wenn man bewusst in Kauf nimmt, dass man sie neu schreiben muss, wenn sich Rahmenbedingungen massiv ändern?
Die Argumentation ist nicht neu. Und weitergedacht kommen wir dann wieder dazu, dass man sie so schreiben muss, dass man einzelne Bausteine problemlos neu schreiben bzw. austauschen kann. Weil ein Big Fat Rewrite, naja, wir wissen ja aus Erfahrung wie gut das funktioniert. Nämlich zumindest im sogenannten Produktgeschäft so gut wie gar nicht.
Ist das wiederum der Grund wieso Du Lösung vs. Implementierung ansprichst? Wenn mein Eventsystem als Eventsystem im allgemeinen integriert ist und nicht als konkretes Eventsystem e, dann ist ein Rewrite oder Austausch einfacher. Ist es das, was Du sagst?
Da finde ich die Referenz auf Uncle Bobs Clean Architecture (http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html) wieder erwähnenswert. Letzten Endes ist sein Vorschlag, statt Lösungsabstraktionen zu integrieren alles abstrakt als 'Gateway' zu betrachten und damit effektiv die Abhängigkeiten zu Lösungen weitgehend zu eliminieren. Egal ob Eventsystem, Datenbank, ESB, Webservice: Ich schicke meine Daten an ein Gateway und nur das Gateway weiß, was das eigentlich bedeutet. Und ich implementiere ein Interface des Gateways, so dass das Gateway mir auch aktiv Bescheid sagen kann.
Das ist jetzt wieder sehr Source-Code-spezifisch und nicht so sehr in Systemen gedacht. Aber vielleicht hilft es der Diskussion,
Natürlich kann man Software besser schreiben, wenn man die Natur der Sache besser versteht.
Wenn ich annehme, Anforderungen sind konstant, dann baue ich Software so, dass sie konstante Anforderungen erfüllt. Das ist ökonomisch.
Wenn konstante Anforderungen aber eine Fehlannahme sind und ich baue Software immer noch für konstante Anforderungen... dann ist das unökonomisch. So ist der Zustand aber heute im Wesentlichen.
Beim Vorgehensmodell sind wir schon weiter als bei den Strukturen. Die spiegeln noch nicht die Erkenntnis von Agile und Lean wider.
In den meisten Fällen wir Software heute so gebaut wie vor 20 Jahren. Oder sogar noch schlimmer! Denn vor 20 Jahren war "Entwurf" noch keine Lästigkeit.
Heute jedoch... Was ist Entwurf? Wie macht man das? Und wie macht man das für ein Zeug, dessen Umwelt sich ständig ändert?
Wir müssen die Realität begreifen. Es geht um Evolution. Lösungen müssen beständig sein - und Implementierungen müssen dafür anders aussehen.
Die Lösung als stehende Welle geformt aus wechselnden Implementierungen. So wie ein Wald über Jahrhunderte besteht - und doch ständig seine Bäume wechseln.
Hier dazu auch noch mal ein paar Gedanken: http://blog.ralfw.de/2012/09/form-follows-feasibility.html
Interssante Aussagen:
>Rewrite statt refactor
>.. so schreiben muss, dass man einzelne Bausteine problemlos neu schreiben bzw. austauschen kann
>.. Daten an ein Gateway und nur das Gateway weiß, was das eigentlich bedeutet
Ja, ich denke Composition von kleinen Elementen, aus denen ganze neue Systeme mit neuem Verhalten entstehen, scheint ein guter Weg zu sein.
Die Abhängigkeiten sollten minimiert (meinetwegen nur zum abstrakten Gateway) werden. Die Schnittstelle dazu ist schmal, einfach - vielleicht so:
synchron:
Action
Func
oder asynchron:
Action> - die zweite Action ist der Callback
Grosse Ähnlichkeiten mit FP (Funktional Programming). Sind Funktionen die kleinste brauchbare Granilarität und der Kompositionskontext (alias Gateway) sind die Komponenten? Wir bewegen uns also weg vom imperativen Stil zu FP? Objektorientierung vornehmlich in "Reinstform", damit meine ich Kapselung, Information Hiding und Nachrichten/Botschaften zwischen diesen Kapseln?
Um die Kopplungsgrade in den Griff zu bekommen (zur Laufzeit Impl. A in Version 1.1 gegen V1.2 auszutauschen), muss man noch die Versionierung / Kompabilität beachten (wie z.B. OSGI), im Falle loser Kopplung muss das Marshalling mit Versionsinformationen versehen werden und entsprechende Regeln bei Schemaänderungen greifen.
Software = Composition of components
Components = Compostions of Functions
Functions = atomar
Die Kompositionskontextes sind durch eine Konfiguration definiert und die Kommunikation sind versionsichere Nachrichten.
synchron:
Action<T>
Func<T,R>
asynchron:
Action<T,Action<U>>
Action<U> ist der Callback.
Der Kompositionskontext ist im Kleinen die z.B. die FlowRuntime.
Die grösseren Einheiten sind verschachtelte FlowRuntimes, die z.B. über IOC verdrahtet sind = Gateway.
Welche Nachricht im Gateway was bedeutet (Semantik) und was, wohin (Routing) weiterzureichen ist, ist in der Gateway-Konfiguration (z.B. IOC-Configuration oder DSL) hinterlegt.
Die Implementierungssprache spielt im Sinne der POLYGLOT-Programming eine untergeordnete Rolle, das Problem / die Aufgabe definiert die Zielsprache. Alles interoperabel und im Rahmen der Kompabilitätsreglen neutral zu konkreteren Implementierungsversionen.
Ob Flow Runtimes bei evolvierbareren Strukturen eine Rolle spielen, lasse ich mal dahingestellt.
Sicherlich aber geht es darum, mehr Funktionseinheiten zu haben, die erstens stärker entkoppelt sind und zweitens autonom.
Dann können sie besser ausgetauscht werden. Und dann nutzen sie die zunehmende Zahl an Kernen.
Die Entkopplung sollte dann auch so aussehen, dass sie plattformunabhängig ist, damit man "Anwendungen" aus Teilen zusammensetzen kann, die mit unterschiedlichen Plattformen realisiert sind (.NET, Ruby, Clojure, Scala, Python...).
Solch starke Entkopplung denken wir heute noch zuwenig, glaub ich. Und wenn, dann in zu großer Granularität.
Multicores teile ich dem Aspekt Ausführungskontext zu.
Mit einem interoperablen Protokoll ist man recht plattformfrei.
Kopplungsgrade teile ich dem Kompositionskontext zu (in process, different processes, distributed).
Vielleicht ist ein Aktor-Modell (ala ERLANG) ein guter Weg. Scala, Go, Akka, ... ich erkenne eine Vielzahl von guten Ansätzen und Lösungen, die eine lose Kopplung ermöglichen.
Was heisst denn 'autonom'?
Bedeutet das, die Funktionseinheit wird in einem eignen Prozess ausgeführt?
Oder ist 'autonom' = frei von Abhängigkeiten?
Oder bedeutet es frei von Seiteneffekten (Functional Porgramming)?
Kommentar veröffentlichen