Warum sind manche Dinge eigentlich so schwer in der Softwareentwicklung? Verteilte Anwendungen sind imperformant, SOA wird als Maximierung Webservice-Endpunkten verstanden, Anwendungen sind objektorientiert, aber leider unwartbar, ein automatischer Build ist in vielen Projekten ein Fremdwort usw. usf. Warum? Liegt es an unausgereiften Konzepten und ungenügenden Technologien?
Ich glaube, nicht. Mein aktueller Gedanke ist vielmehr, dass allzuoft in der Softwareentwicklung das Unmögliche versucht wird. Sie versucht unrealistische Sprünge zu machen. Entwickler können aber nicht springen. Sie können nur einen Schritt nach dem anderen gehen.
Um zu verstehen, was ich damit meine, zunächst ein kleiner Ausflug in die Psychologie... Sie können aber auch - ein letztes Mal ;-) - springen und gleich beim für die Softwareentwicklung relevanten Abschnitt "Ebenen der Softwareentwicklung" weiterlesen.
Bewusstseinsstufen
Bei der Lektüre von Ken Wilber bin ich mal wieder über Integrale Psychologie und das Modell der Bewusstseinsstufen gestolpert. Nach ihr können Menschen in unterschiedlichen Bereichen (auch Linien genannt, z.B. kognitive Intelligenz, emotionale Intelligenz) auf unterschiedlichen Bewusstseinsstufen sein (auch Ebenen genanannt, z.B. Mythisch, Rational). Wieviele Bewusstseinsstufen es genau sind, dazu haben verschiedene Schulen auseinandergehende Meinungen. Über drei ganz grobe herrscht jedoch wohl Einigkeit:
- Bewusstseinsstufe 1: Prä-Konventionell, egozentrisch
- Bewusstseinsstufe 2: Konventionell, gruppenzentrisch
- Bewusstseinsstufe 3: Post- oder Trans-Konventionell, weltzentrisch
Die geistige Entwicklung eines Menschen verläuft in vielen Linien von der niedrigsten Stufe zu höheren. Auf den unterschiedlichen Linien kann er auf verschiedenen Ebenen sein. Die höchste Ebene - allemal in sehr feingranularen Bewusstseinsstufenmodellen - erreichen allerdings nur die allerwenigsten.
Ausgangspunkt der Entwicklung bei allen Menschen ist eine egozentrische Weltsicht. Auf dieser Ebene sind Menschen selbstbezogen, ihr eigenes Wohl ist ihnen am wichtigsten. Neugeborene und auch noch Kleinkinder sind ganz natürlich auf dieser Ebene. Alles muss sich um sie drehen. Sie müssen komplett versorgt werden, also fordern sie das auch ein. Alles geht auf dieser Ebene - solange es unsere Bedürfnisse befriedigt.
Erst allmählich lernen wir dann, von uns selbst abzusehen. Da sind noch andere Menschen in unserer Umgebung, die gehören zu uns. Wir dürfen sie nicht aus dem Blick verlieren, weil es uns sonst schlecht erginge. Die gruppenzentrische Bewusstseinsstufe wird erklommen. Um mit den anderen auszukommen oder sie uns gar wohlgesonnen zu stimmen, lernen wir, uns an Regeln zu halten. Diese Konventionen sind gruppenspezifisch und halten sie zusammen. Familien, Clans, Dorfgemeinschaften, Nationen oder Glaubensgemeinschaften sind Beispiele für solche Gruppen, denen wir uns auf der 2. Bewusstseinsstufe zugehörig fühlen.
Geht die Bewusstseinsentwicklung weiter, dann erkennen wir, dass die Welt nicht nur aus unserer Gruppe besteht. Da sind andere Gruppen mit anderen Konventionen. Wir lernen unsere bisherigen Konventionen zu transzendieren. Die Gruppe wird ein Teil der größeren Welt. Unser Bewusstsein lässt Pluralität nicht nur zu, sondern freut sich an ihr; wir sind weltzentrisch. Das bedeutet nicht, dass wir nach keinen Regeln mehr leben würden. Regeln verlieren nur ihren Absolutheitsanspruch. Wir wählen unsere Regeln selbst - und fühlen uns frei, sie zu hinterfragen und neu zu definieren.
Unmöglich zu springen
Keine dieser Bewusstseinsebenen ist gut oder schlecht. Sie stellen einfach nur Entwicklungsstufen dar. Es sind Haltepunkte auf einem Lebensweg. Wie lange jemand auf ihnen verweilt, ist ganz unterschiedlich. Zu welcher Bewusstseinsstufe er in welcher Linie es während seines Lebens schafft, auch das ist ganz unterschiedlich.
Zentral für das Verständnis dieser Ebenen ist, dass keine übersprungen werden kann. Wir können nicht ohne egozentrisch gewesen zu sein einfach bei Gruppenzentrizität beginnen. Jeder muss auf allen Ebenen unterhalb seiner aktuellen gewesen sein. Es gilt - wenn auch auf einen unüblichen Bereich angewandt - das alte natura non facit saltus.
Ein Vergleich mit der MusikEbene 1: Sehr kleine Kinder leben in ihrer eigenen Musik- oder besser Tonausdruckswelt und produzieren eher Krach. Sie kennen noch keine musikalischen Konventionen. Sie sind egozentrisch, wenn sie einfach Spaß an Klanghölzern oder Trommeln haben - der allerdings Erwachsene die Flucht ergreifen lässt. Durch Anleitung betreten Kinder dann die Welt der Kinderlieder. Sie singen einfach. Und wenn es ihnen immer noch Spaß macht, dann singen sie laut und häufig und auch unerschrocken falsch. Sie haben die Egozentrik noch nicht verlassen.Ebene 2: Im nächsten Schritt lernen Kinder dann ein Instrument und betreten damit die Ebene der Konventionen. Sie werden mit Regeln vertraut gemacht, wie Musik in ihrer Gruppe sich anzuhören hat. Diese Regeln sind für abendländische Kinder anders als für indische. Zunächst sind die Melodien einfach, dann werden die Musikstücke immer komplizierter. Von der klassischen Musik bis zur Pop-Musik regieren die Konventionen. Ebene 3: Aber auch Jugend Musiziert Preisträger oder gar Orchestermusiker können sich noch weiterentwickeln. Sie können zum Einen über ihre Musikkonventionen hinausblicken und die Vielfalt der Musiktraditionen schätzen oder gar anwenden lernen. Weltmusik ist das Ergebnis. Zum Anderen können sie ihre Konventionen transzendieren und z.B. Gefallen an Jazz finden oder sich an 12-Ton-Musik versuchen. Auch wenn Jazz und 12-Ton-Musik immer noch Regeln unterliegen, definieren sie doch eine höhere "Musikbewusstseinsebene" als Volkslieder, weil sie deren Konventionen anerkennen, reflektieren und dann über sie hinausgehen. |
Jede Bewusstseinsstufe definiert sozusagen einen Horizont, bis zu dem und innerhalb dessen Umkreis wir die Welt wahrnehmen. Was wir wahrnehmen, beziehen wir immer auf das innere dieses Gesichtskreises. Auf der präkonventionellen Ebene beziehen wir alles auf uns; unser Wohlbefinden steht im Mittelpunkt. Alles wird daraufhin eingeordnet: Ist es gut für uns, ist es schlecht für uns? Dasselbe gilt für die Gruppe auf Ebene 2 und für die Welt auf Ebene 3.
Bewusstseinsebene bedeutet, dass wir unfähig sind, die Welt anders zu sehen. Wir können nicht umhin, alles auf uns oder unsere Gruppe zu beziehen. Deshalb sind wir ja auf Ebene 1 oder 2. Bewusstseinsstufen sind wie Brillen, die wir nicht abnehmen können. Allerdings können wir uns immer höher entwickeln, sozusagen die Tönung der Brille ändern und ihren Blickwinkel erweitern.
Der Prä-/Trans-Trugschluss
Auf welcher Bewusstseinsebene befindet sich nun ein Mensch? Um bei den drei groben Ebenen zu bleiben: Ist er egozentrisch oder konventionell oder transkonventionell? Interessanterweise kann man das nicht so einfach bestimmen, sagt die Theorie. Denn oberflächlich (!) können prä- und transkonventionelle Menschen in ihren Sichtweisen/Antworten/Handlungen gleich aussehen.
Auf die Frage, "Darf man bei Rot über die Ampel gehen?" würden die Antworten von Menschen auf Ebene 1, 2 und 3 lauten: Ja, Nein, Ja.
- Ebene 1: "Ja, klar! Ist mir doch egal, was die Ampell zeigt. Ich geh´ rüber, wenn´s mir passt."
- Ebene 2: "Nein, man darf nur gehen, wenn die Ampel grün zeigt. Wo kämen wir hin, wenn niemand mehr auf die Verkehrsregeln achten würde?"
- Ebene 3: "Ja, man darf auch bei Rot gehen, wenn die Umstände es zulassen oder gar gebieten."
Anhand der knappen, oberflächlichen Ja/Nein-Antwort lassen sich prä- und transkonventionelle Menschen also nicht so einfach unterscheiden. Die Theorie nennt das den Prä-/Trans-Trugschluss: Menschen werden aufgrund ihrer Antwort auf Ebene 3 angesiedelt, obwohl sie sich noch auf Ebene 1 befinden.
Macht das etwas, die Antwort ist doch gleich? Ja. Einen Egozentriker nicht zu erkennen, kann sehr schädlich sein. Hinter seinem Ja im obigen Beispiel steht kein Verantwortungsbewusstsein; das gehört einfach nicht zu seiner Bewusstseinsstufe. Wenn jemand auf einer unteren Ebene meint, er sei schon auf einer höheren, kommt es also mindestens zu Missverständnissen und Friktionen, wenn nicht gar zu ausgewachsenen Konflikten. Ebene n hat einfach einen anderen Horizont als Ebene n+1. Was auf Ebene n+1 sichtbar ist, mag Ebene n unsichtbar sein. Dann wird es schwer, solches (noch nicht) Sichtbare zu verstehen. Menschen auf einer Ebene müssen sich überfordert fühlen, wenn sie mit Fragen und Konzepten höherer Ebenen konfrontiert werden. Einem Erstklässler das Weltfinanzsystem erklären zu wollen, kann nicht gelingen.
Ein Vergleich mit der MusikDem musikalischen Laien erscheint womöglich das quasi ununterscheidbar gleich, was kleine Kinder an Musik produzieren und was atonale Musiker von Weltrang wie Arnold Schönberg komponieren. Der übliche musikalische Laie steht jedoch auf Ebene 2 und versucht nun Ausdrücke der ihm bekannten Ebene 1 mit der ihm (noch) unverständlichen Ebene 3 zu vergleichen. Das muss scheitern; es ist also kein Wunder, dass es zu Prä-/Trans-Verwechslungen kommen kann. |
Aber nochmal: Sich auf einer Ebene zu befinden, ist weder gut noch schlecht, richtig oder falsch. Alle Menschen fangen auf der untersten Stufe an. Und aus den unterschiedlichsten Gründen entwickeln sie sich mehr oder weniger weit.
Ebenen der Softwareentwicklung
Mir scheint das Modell der Bewusstseinsebenen und Entwicklungslinien so plausibel und nützlich, dass ich es nun auf die Softwareentwicklung anwenden möchte. Ich glaube, es gibt Ebenen der Softwareentwicklung, es gibt unterschiedliche "Bewusstseinsebenen" für Softwareentwickler, d.h. Stufen ihrer Entwicklung.
Zunächst einmal sehe ich dafür in der Softwareentwicklung eine eigene Linie. Ich nehme einfach mal soetwas wie einen SEQ, einen SoftwareEntwicklungsintelligenzQuotienten an. So wie Menschen einen unterschiedlichen IQ oder EQ (Emotional intelligence) haben, so haben Softwareentwickler auch einen SEQ. Der mag zu einem gewissen Teil unveränderlich sein, aber ganz sicher kann er durch Ausbildung und Übung stark entwickelt werden.
Wie andere Bewusstseinslinien läuft die des SEQ nun auch von niedrigen zu höheren Bewusstseinsebenen, d.h. Stufen mit einem immer weiteren Horizont und tieferer Reflektion. Hier mal ein Vorschlag für diese SEQ-Ebenen. Ich benenne sie einfach mit dem Konzept, das ich bei ihnen für jeweils besonders charakteristisch halte. Sie stellen für mich den zentralen Lerninhalt oder Fokus dar.
Die Entwicklung des Softwareentwicklers beginnt beim Algorithmus, d.h. bei Anweisungssequenzen. Er lernt, Statements zur Lösung eines Problems aneinander zu reihen: Ausdrücke, Zuweisungen, Kontrollstrukturen. Das EVA-Prinzip und die Trennung von Daten und Funktionen gehören auf diese Stufe.
Auf der nächsten Ebene werden Anweisungen zu Gruppen zusammengefasst und durch Unterprogramme wiederverwendbar gemacht. Der Softwareentwickler lernt, wie er selbst Funktionen als Zusammenfassungen von Anweisungen definieren kann. Auf der Algorithmus-Ebene hat er sie nur genutzt. Zur Ebene 2 gehören auch Konzepte wie Scope und die Unterscheidung zwischen Stack und Heap.
Die nächste Ebene ist wieder durch eine Zusammenfassung charakterisiert: Objekte/Klassen fassen Daten und Funktionen zu Strukturen auf dem Heap zusammen. Das ist der entscheidende Schritt über Ebene 2 hinaus. Vererbung halte ich für nicht so essenziell, dass sie schon auf dieser Ebene gemeistert werden müsste.
Ebene 4 bricht mit dem rein sequenziellen Programmiermodell. Bisher hier war die Reihenfolge, in der Anweisungen abgearbeitet wurden, klar aus dem Quellcode ablesbar. Mit Funktionszeigern können Funktionen jedoch so parametrisiert werden, dass man ihrem Quellcode nicht mehr ansehen kann, woentlang der Kontrollfluss in welchem Fall genau fließt; das kann nämlich vom Inhalt von Funktionsvariablen abhängen. Ruft eine Anweisung eines solche Variable auf, feuert sie über diesen Callback einen Event, der an einer Stelle bearbeitet wird, die nur dem bekannt ist, der die Variable gesetzt hat. Das kann eine aufrufende Funktion sein. Da virtuelle Methoden Funktionszeiger voraussetzen, scheinen mir Vererbung und abstrakte Klassen auch in diese Ebene zu gehören.
Ebene 4 der SEQ schließt für mich die grundlegendere Stufe der Egozentrik ab. Bis hier konnte der Softwareentwickler sich mit seinem Code allein wähnen. Das ändert sich mit Ebene 5...
Auf der nächsten Ebene lernt der Softwareentwickler, dass Funktionen auch gleichzeitig ausgeführt werden können. Sie können auf verschiedenen Threads zusammen versuchen, ein Ziel zu erreichen. Dafür müssen sie Regeln einhalten. Parallelität braucht Konventionen für die Koordination der konkurrierenden Funktionen und den gemeinsamen Ressourcenzugriff.
Aber nicht nur Funktionen können parallel laufen. Auch die Softwareentwicklung findet parallel statt. Komponenten (d.h. binäre Codeeinheiten mit separater Spezifikation) sind zur Organisation paralleler Entwicklung sehr hilfreich. Sie isolieren Entwickler und Entwicklungen von einander (Komplexitätsreduktion), machen produktiver (echte Parallelentwicklung aller Komponenten) und erleichtern punktgenaues Testen (durch separate Kontrakte begünstigte Attrappen). Um quasi industriell im Team zu entwickeln, sind also Konventionen einzuhalten: Architektur, Komponentenstruktur, IoC, Attrappen sind solche Konventionen, die die Zuammenarbeit erleichtern.
Auf der nächsten Ebene wird der bisherigen "Parallelität im Kleinen" zu Steigerung von Responsiveness und Performance eine "Parallelität im Großen" gegenübergestellt. Anwendungen, die aus mehreren Prozessen bestehen, verteilen ihren Code zur parallelen Ausführung, um skalierbarer oder noch performanter zu sein. Am einfachsten ist die Kommunikation zwischen diesen Prozessen mittels RPC. Für eine grundsätzliche Verteilung muss zu den bis hierher vertrauten Konzepten also nur wenig dazugelernt werden. C/S, COM+, Webservices und .NET Remoting gehören auf diese Ebene. Die Konventionen von Ebene 7 sind z.B. die Kontrakte der verteilten Kommunikation und die Planung des Deployments bzw. der Administration. Die Prozesse in einer verteilten Anwendung müssen sich auf einander verlassen können.
Mit Ebene 7 ist die Entwicklung gruppenzentrischer Entwicklerbewusstheit abgeschlossen. Der Softwareentwickler hat gelernt, dass er mit seinem Code nicht allein ist. Zur Laufzeit und im Entwicklungsprozess gibt es Parallelität, die zur Einhaltung von Regeln zwingt. Wer diese Regeln bricht, muss nicht nur für sich Konsequenzen gewärtigen, sondern beeinflusst immer auch andere.
C/S und RPC sind Konzepte für überschaubare Anwendungen. Was aber, wenn die Applikationen weiter wachsen? Nachrichtenorientierung ist das Mittel, um über eine kleine Gruppe von Prozessen hinaus zu blicken. Sie akzeptiert, dass es auch andere Plattformen geben kann; sie akzeptiert, dass verteilte Kommunikation ganz anderen Kriterien folgen muss als lokale. RPC versucht die Verteilung mit Mitteln der lokalen Kommunikation zu kaschieren. Entwickler glauben dadurch, mit ihren lokalen Konventionen auch verteilte Anwendungen realisieren zu können. Das ist aber ein Trugschluss - und mit dem räumt die Nachrichtenorientierung auf. Sie transzendiert also die ego- und gruppenzentrischen Konventionen und Konzepte und öffnet den Blick für eine weitere Welt mit anderen Regeln, die einen bewussteren Umgang erfordern.
Nachrichtenorientierung ist trotz ihrer Kritik an RPC allerdings zunächst immer noch der Punkt-zu-Punkt-Kommunikation verhaftet. Auch nachrichtenorientiert angesprochene WCF-Servicemethoden sehen mehr oder weniger aus wie lokale Funktionen. Das ändern Event-driven Architectures (EDA). Wie lokale Events kehren sie das Denken um. Services werden nicht mehr direkt kontaktiert, sondern auf Warteschlangen oder Bussen (Enterprise Service Bus) registriert. Das entkoppelt Clients und Services massiv; die Client-Service-Regeln wird transzendiert. Die Orts- und Plattformunabhängigkeit steigt.
Mit SOA werden schließlich verteilte Funktionalitäten auf höherer Ebene wiederum zusammengefasst. Zeit und Ort und Granularität für Dienstleistungen unterliegen keinen Konventionen mehr, die Prozess, Maschine oder Plattform vorgeben könnten. Services können über das Internet weltweit verteilt werden. Softwareentwicklung ist damit auf einer wahrhaft weltzentrischen Ebene angekommen.
Konsequenzen des Ebenenmodells für die Softwareentwicklung
Ob die Ebenen der Entwicklung eines Softwareentwicklungsbewusstseins nun genau so geschnitten sind oder in dieser Reihenfolge aufeinander liegen sollten, finde ich nicht so wichtig. Ich halte den obigen Vorschlag für ausreichend gut, um ihn als Erklärungs- und Planungsmodell zu nutzen. Er muss nicht final, sondern nur angemessen sein. Nicht welche Ebenen genau es gibt, sondern dass es überhaupt Ebenen gibt, ist entscheidend.
Dass mein Vorschlag von einigen derzeit kanonischen Vorstellungen abweicht, ist mir bewusst. Dennoch habe ich die Ebenen so angeordnet, weil sie mir so am plausibelsten bzw. natürlichsten erscheinen. Aber ich bin offen für Alternativvorschläge.
Was nützt der ganze Aufwand aber nun? Wozu dieses Modell? Ich meine, es hilft, heutige Probleme zu erklären und sie zukünftig zu vermeiden. Darüber hinaus bzw. deshalb hilft es aber auch, Ausbildung zu planen.
Seiner Erklärungskraft liegen drei Annahmen zugrunde:
- Annahme - Entwicklungsstreuung: Softwareentwickler befinden sich auf ganz unterschiedlichen Ebenen.
- Annahme - Fehlerhafte Selbsteinschätzung: Softwareentwickler wähnen sich oft auf einer höheren Ebene, als sie tatsächlich schon erreicht haben.
- Annahme - Fehlerhafte Fremdeinschätzung: Softwareentwickler werden von anderen auf einer höheren Ebene als der erreichten angesiedelt.
Dass Softwareentwickler sich auf unterschiedlichen Ebenen befinden, kann - so glaube ich - kaum strittig sein. Ausbildungen und Erfahrungshintergründe sind einfach unendlich vielfältig.
Angesichts eines gewöhnlich weniger differenzierten Entwicklungsbildes werden die Konsequenzen solch unterschiedlicher Entwicklung falsch eingeschätzt. Wo es nur 2 oder 3 sehr allgemeine Entwicklungsstufen gibt, z.B. Junior Programmer, Senior Programmer und, hm, Architect, da fällt auch die Wahrnehmung von Unterschieden (oder weniger neutral: Defiziten) anders aus. Man glaubt allemal, sie ließen sich relativ leicht ausgleichen. Eine Schulung in einer neuen Technologie und fertig.
Das halte ich aber für einen fundamentalen Trugschluss. Zusammen mit der Prämisse, dass Entwicklungsstufen nicht übersprungen werden können und den vorstehenden Annahme, ist für mich vielmehr deutlich, warum verteilte Anwendungen trotz oder wegen WCF immer noch vielen Entwicklern Probleme machen. Und mir ist nun auch klar, warum die SOA-Botschaft nicht so ankommt, wie sie ankommen könnte oder sollte.
Wenn WCF (Ebene 8) Entwicklern nahegebracht werden soll, die gerade mal Ebene 4 (Events) gemeistert haben, dann kann das nicht wirklich funktionieren. Wenn SOA (Ebene 10) gepredigt wird, wo gerade mal RPC (Ebene 7) verstanden wurde, dann kann das nicht wirklich funktionieren.
Technologie- und Konzeptverkäufer kennen ihr Publikum zu wenig. Sie sind ihnen oft um Ebenen voraus. Das liegt an der nur groben Klassifizierung von Entwicklerbewusstheit/-erfahrung. Es kommt nicht darauf an, WCF oder SOA usw. einfach nur Entwicklern mit einer bestimmten Zahl von Berufsjahren zu predigen. Es kommt darauf an zu erkennen, auf welchem Bewusstseinslevel sie sind, ja, sein können.
Bewusstseinslevel mag mit Berufsjahren korrelieren - aber einen Kausalzusammenhang gibt es so einfach nicht. Wer SOA säen will, der sollte also nicht fragen, wieviele Berufsjahre im Publikum der Durchschnitt sind, sondern ob der Durchschnitt der Entwickler Ebene 9 erreicht hat. Denn nur wer Ebene 9 gemeistert hat, kann wirklich auf Ebene 10 klettern. Allen anderen ist das Verständnis für das, was Ebene 10 will, mehr oder weniger verschlossen.
Und nochmal: Das ist keine Wertung. Auf der einen oder anderen Ebene zu sein ist weder gut noch schlecht. Schlecht ist allerdings eine fehlerhafte Selbst- oder Fremdeinschätzung. Ihre Folge sind nämlich falsche Anwendungen von Technologien und Konzepten. Und das kostet viel Zeit und Geld.
Zu erkennen, auf welcher Ebene sich ein Entwickler befindet, ist nun durch den Prä-/Trans-Trugschluss nicht leicht. Entscheidet er sich für den Einsatz einer Technologie (z.B. RPC), weil er die Alternativen abwägen konnte (Trans) oder weil er keine Alternativen hatte (Prä)?
Ergebnis 1: Ich glaube, dass Tools, Technologien und Konzepte heute vielfach falsch eingesetzt werden, weil Entwickler versuchen mit ihnen umzugehen, deren SEQ-Bewusstseinsstufe ihrem Einsatz noch nicht entspricht. Da hilft dann auch kein Schnellkurs, der würde nämlich einen Sprung versuchen. Springen ist aber unmöglich. Helfen kann nur, die fehlenden Ebenen schrittweise zu erklimmen.
Niemand schätzt sich oder andere willentlich falsch ein. Fehleinschätzungen wird vielmehr durch eine undifferenzierte Betrachtung der Entwicklung von Programmierkompetenz Vorschub geleistet. Und auch der Glaube an eine ausreichende Ausbildung tut seinen Teil dazu.
Mein Informatikstudium vor 20 Jahren (also noch vor der Objektorientierung) hat mich lediglich durch die ersten drei Ebenen (Algorithmus, Funktion und Event/Callback) geführt. Von Parallelität und RPC habe ich dort nichts gehört. Ein Arbeitgeber (oder Technologieanbieter) hätte aber natürlich zurecht angenommen, dass ich auch die Ebenen dank meiner Ausbildung gemeistert habe. Ein Trugschluss.
Heute ist es nicht sehr anders. Von einem Dipl-Informatiker oder BA-Absolventen kann man nicht mehr Ebene 4 erwarten. Darüberliegende Ebenen werden vielleicht in Vorlesungen gestreift, doch das ist nicht gleichzusetzen mit ihrer Meisterung. Eine SEQ-Bewusstseinsebene wirklich zu erreichen bedeutet, mit ihren Technologien und Konzepte wirklich gründlich Erfahrungen gesammelt zu haben. Kann das aber durch die Bank von Informatikstudenten in Bezug auf Parallelverarbeitung oder Komponentenorientierung gesagt werden? Kaum.
Wie gesagt: Es geht nicht darum, dass diese Ebenen in der Ausbildung nicht gestreift würden. Aber solide Bewusstseinsbildung findet nicht statt. Solange in der Ausbildung nicht ausgiebig Erfahrung mit Semaphoren, Deadlockvermeidungsstrategien oder Koordinationsdatenstrukturen gesammelt wird, kann von einem Bewusstsein auf Ebene 5 nicht gesprochen werden. Dasselbe gilt für Contract-first Design, IoC, IDL, Attrappen und schließlich automatische Builds, die aus meiner Sicht zu Ebene 6 gehören.
Projektverantwortliche nehmen aber legitimerweise an, dass zur Ausbildung gehört, alle Ebenen der Softwareentwicklung so tiefgehend zu behandeln, dass am Ende Softwareentwickler stehen, die zumindest sicher auf Ebene 8, wenn nicht sogar auf Ebene 9 oder 10 zu verorten sind.
Leider ist das nicht die Realität. Deshalb kommt es zu Fehleinschätzung. Deshalb kommt es zu teuren Fehlnutzungen von Technologien und Konzepten.
Ergebnis 2: Die Ausbildung sollte ein klares Ebenenkonzept wie oben entwickeln und am state-of-the-art ausrichten. Und sie sollte dafür sorgen, dass ihre Absolventen je nach Abschluss ein gut ausgeprägtes und SEQ-Bewusstsein auf erwartbarer Ebene haben. Erwartungshorizonte für die einzelnen Ebenen sollten mit der Industrie abgestimmt oder zumindest öffentlich sein. Die derzeitigen Curricula sind ein guter Ausgangspunkt, aber ihnen mangelt es an einem expliziten Ebenenkonzept. Sie lassen sich deshalb schwer vergleichen und stehen in keinem Gesamtzusammenhang. An ihnen kann nicht abgelesen werden, wieviel Anteil an einem Maximalbild sie haben.
Ergebnis 3 und Fazit: Ich halte es für sehr nützlich, die Softwareentwicklung insgesamt und den einzelnen Softwareentwickler ins Verhältnis zu einem SEQ-Bewusstseinsstufenmodell zu stellen. Ob es das obige oder ein anderes ist - egal. Solange die Prämisse anerkannt wird, dass es überhaupt Stufen gibt und höhere nicht "angesprungen", sondern ausschließlich durch Schritte über niedrigere erreicht werden können, solange ist es mir recht. Eine Differenzierung in mehr als 4-5 Ebenen setze ich ebenfalls voraus.
Mir hat diese Strukturierung der Softwareentwicklung jedenfalls schon sehr geholfen. Wenn es zu Missverständnissen kommt oder ich Unverständnis bemerke, dann kann ich jetzt viel gezielter abklopfen, wo es hakt. Durch Fragen kann ich leicht klären, auf welcher SEQ-Stufe Gesprächspartner stehen. Wenn ich das weiß, kann ich zusammen mit ihnen überlegen, wie ich ihnen auf die für ihre Situation nötige Ebene hinaufhelfe. Das mag dann etwas Zeit kosten - am Ende ist es aber unumgänglich. Entwickler machen einfach keine Sprünge.
11 Kommentare:
Hi Ralf
sehr interessantes Posting, dass ich aus meiner Erfahrung bestätigen kann.
Zum einen Rückblicken bei meiner eigenen Entwicklung (die sicher noch lange nicht am Ende ist) und zum anderen was ich bei andern Beobachten kann.
Es ist unumgänglich jetzt Stufe zu "durchleben" um sich letztendlich weiter zu entwickeln.
Ich habe schon versucht dies in meine Lernstrategiien zu integriere ich dem ich versuche bewusst all diese Stufe zu nehmen und iterativ Probleme auf dem jeweils nächsten Level immer wieder zu lösen.
Wenn mann einfach nur "das Perfekte System" an der Hand hat ohne die Erfahrung aus der Vorhergehenden Stufen zu haben, fehlt einem die Sensibilisierung für die Vorteile und meiner Meinung nach auch die Fähigkeiten sich darüber hinaus zu entwickeln.
Hi Ralf,
wieder ein sehr schöner Post von dir. Deine Rubrik Softwarephilosopie finde ich herausragend! Wäre doch mal was für die dnp... Um mal auf deinen Inhalt einzugehen, soweit mir das jetzt überhaupt möglich ist (muss nochmal alles in Ruhe reflektieren). Ich stimme dir zu mit den Bewußtseinsstufen. Ich beschäftige mich auch schon seit einiger Zeit damit (Buddhismus) und kann daraus auch schon viel für meine Softwareentwicklung ableiten. Um nur mal kurz in diese Richtung abzuschweifen. Jedem ist die Buddhanatur (also das Wesen des Vollkommenen, des Erleuchteten inne) Es benötigt der Entwicklung, des Erkennens dessen, was wirklich ist.
Einen schönen Wegbereiter dazu hat mir das Buch "Wie die Dinge sind geben". Vielen fehlt einfach das Verständniss, obwohl sie es sehr wohl können! Vielleicht sogar noch besser als ihre Meister. Nur leider gibt es eben wenige dieser Meister. Um so schöner finde ich es auf dieser Seite jemanden zu finden, der diesen Inhalt so gut auf Sotware übertragen kann. Ich selbst würde mich auf Stufe 7 einordnen an der Schwelle zu 8. Obwohl mir von parallelität nicht viel in meinem Arbeitsalltag über den Weg gelaufen ist. Klar habe ich mit Threads gearbeitet und verschiede "Appartments besucht" ... aber Eben auf einer sehr einfachen Ebene. Ich muss dir eben hier in einem Punkt wiedersprechen. Es geht nicht immer darum, dass jemand erst alles durchlebt haben muss um zu verstehen wie die Sache in seiner Natur funktioniert. Manchmal reicht es den Ursprung zu verstehen und duch allgemeine "Gleichungen", sozusagen für jeden gültige Lehr- und Leitsätze, zu belegen.
Kann also jedem dieses Buch hier ans herzlegen "http://www.lama-ole-nydahl.de/buch_dinge.htm"
Und ob nur der lange Diamantweg gegangen wird oder einem die Erleuchtung/Talent (oder wie auch immer du es bezeichnen willst) schon mit in die Wiege gelegt wurde, meicht meiner Meinung nach keinen Unterschied. Es bedarf also nicht der Erfahrung einmal im Koma gelegen zu haben, oder eine schwere Verletzung um zu verstehen das unser Leben wertvoll ist und wir uns erfüllenden danach richten es zu leben. Worin besteht die Erfüllung eines Softwareindividuums? Der eine ist Programmierer und implementiert lediglich vorgaben des Architekten. In der hinsicht kann aber keine Differenzierung gemacht werden auf welcher Stufe sich der Programmierer und auf welcher sich der Architekt befindet. Ist es nicht möglich, dass ein Programmierer die Architektur seines "Meisters" korrigiert, weil er einen Fehler darin erkennt? Daher ist es meiner Meinung nach auch schwer Menschen nach ihren Zeugnissen und Vorkenntnissen zu bewerten! Einzig die persöhnliche Kommunikation und das erleben seines Handels wird dir schlussendlich zeigen was dein Gegenüber kann.
Freue mich schon hier auf die weitere Diskussion zu dem Thema. Du dich aber auch gerne über meinen XING-Account bei mir melden.
Viele Grüße,
Rainer
@Rainer: Freut mich, dass dir mein Ansatz gefällt. Ich stimme mit dir auch weitgehend überein. Insbesondere kann und soll ein Schüler über seinen Meister hinauswachsen bzw. ihn zumindest nicht auf ein Podest heben.
Allerdings sehe ich immer noch nicht die Möglichkeit für Sprünge. Wer wirklich, wirklich auf einer höheren Ebene ankommen will, muss die darunterliegende "gemeistert" haben. Das ist wie in Computergames. Ein Sprung ist mit Cheating möglich - aber man hat einfach manche Erfahrungen dann nicht gemacht, die auf der höheren Ebene zu einem tiefen Verständnis wichtig sind.
Den Aspekt der Zustände habe ich auch ausgelassen. Auf einer Ebene zu sein, den Bewusstseinszustand dauerhaft zu leben, ist eines. Das halte ich für erstrebenswert. Es heißt aber nicht, dass man nicht vorher schon in Zuständen höherer Ebenen sein kann. Zustände sind aber nicht von Dauer. Wer gerade mal auf Ebene 4 ist und dann eine RPC-Kommunikation basteln muss und auch noch hinkriegt, der hat einen höheren Zustand. Aber er ist nicht permanent auf der höheren Ebene. Ihm fehlt für das wirkliche Verständnis Erfahrung "aus dem Dazwischen".
Insofern: Ich bleibe bei der Unmöglichkeit von Sprüngen. Aber ich räume ein, dass die Ebenen anders "geschnitten" sein könnten.
Hey Ralf,
hab deine Gedanken dazu nochmal für mich reflektiert und gleichzeit den neuen Beitrag zur Komponentenorientierung überflogen. Auch hier wieder, trotz des Zufalls, ich finde du hast das schön für dich selbst reflektiert und entsprechend passend herüber gebracht. Das lustige ist, das ich gerade vor einer Stunde über meine Arbeitsweise nachgedacht habe und gemerkt habe, dass ich schon viel Theorie kann, diese auch schon angewendet habe aber ehrlich gesagt mich ja schon wie du gesagt hast nicht auf diesen Ebenen weiter aufhalte. Gerade eben habe ich einen Upload in unser UI und die BusinessLogik eingebaut und mir ist dabei aufgefallen, dass ich von der Theorie etwas abgeschweift habe. Was ist aus den DesignPatterns geworden, die ich jedem ans Herz lege. Ja die schönen Muster (du weißt ja von was ich spreche, Stichwort dnpPatViz) Also weil Bedarf bestand habe ich dann eine Zusatzfunktion über einen Proxy eingebaut. Laos darf ich noch nicht verwenden. Na wie dem auch sei. Und von Komponentenorientierung weit gefehlt. Von wegen ContractFirst. Also habe ich mich jetzt dran gemacht ein Refactoring durchzuführen und meine Contracts nachträglich einzubauen, wo nicht implizit durch die Erfahrung schon vorhanden. Also ich arbeite ja grundsätzlich schon in dieser Richtung aber oft unbewußt. Und da liegt denke ich der Fehler. Um nochmal ehrlich zu sein würde ich mich von der Hirarchie jetzt etwas herunterstufen eher so auf 4. Dennoch weiß ich sehr wohl wie ich auf Stufe 7. Entwickeln und vorgehen muss und könnte es tun. Aber mein Ego ist zu bequem. Und denke ich sind wir bei der größten Sünde aller Menschen, die noch im Egozentrischen Stadium leben. Das ich ist wichtiger und da sich eben die Bequemlichkeit.
Muss ehrlich sagen das ich mich über deinen Post hier sehr freue. Gab mir mal wieder den richtigen anstoß. Also ab jetzt werden ich den Zustand in Ebene 7. wieder einnehmen und bewußt danach programmieren. Rein privat mache ich ja eine ähnliche Entwicklung. Von daher kann es ja nur gut sein sich immer seine Ziele und die höheren Bewußtseinsstufen immer wieder vor Augen zu führen um die Stufen nicht aus selbigen zu verlieren.
Um auf eines meiner Lieblingsfilmzitate zu kommen. Aus Matrix: Traingskampfszene mit Neo und Morpheus im Dojo. "Nicht denken, wissen". Wie es uns der Buddhismus eben auch versucht zu zeigen: Wissen und danach handeln. Ohne nachzudenken und gleichzeitig in diesem Zustand bleiben. Einfach intuitiv handeln. Eben die vollkommene Erleuchtung! Wenn wir quasi einmal die oberste Stufe erreicht habe uns im Binären Nirvana aufhalten sind wir angekommen.
Fazit zu deinem vorherigen Post: Ich denke was du mit Erfahrung beschreibst ist das was ich als unbewußte Ausführung von Arbeit ansehe. Das bewußtmachen und wissen, verstehen wie etwas geht mit der entsprechenden Ausführung. Ich denke nicht das die Erfahrung wichtig ist, sondern das Verstehen. Die Erfahrung hilft uns lediglich zu verstehen!
@Rainer: Wie gesagt, Zustände sind keine Ebenen. Wir können oft Zustände haben - aber eben noch nicht auf der Ebene angekommen sein. Bei Zuständen kann man auch springen. Und häufige Zustände helfen natürlich, sich auf eine Ebene zu bewegen. Aber sie sind eben etwas anderes, temporäres.
Es ist auch nicht schlimm, auf einer Ebene zu sein und nicht auf einer höheren. Schlimm ist es, Zustand und Ebene zu verwechseln. Und schlimm ist Ignoranz/Arroganz. Aber ansonsten: Wenn einer auf Ebene 1 oder 4 oder 7 ist... Macht ja nix. Einfach nur am Ball bleiben und immer wieder "höherer Zustände" suchen. Dann klettert man schrittweise rauf...
Noch kurz zu deinem "sind wir angekommen": Bei den Bewusstseinsstufen im "richtigen Leben" - also, wenn du auf Buddhismus anspielst -, da halte ich inzw genau diese Beschreibung für kontraproduktiv. Sie ist aber verständlich und natürlich eben auf niedrigeren Bewusstseinsstufen, auf denen noch ein ICH existiert. Denn der Trick ist ja, dass sich ganz, ganz oben die Dualität auflöst. Dann gibt es kein ICH-DU mehr. Dann ist nur noch Nondualität und alles eins. War vorher auch schon, hat das ICH aber nicht gemerkt ;-) Das ist unsere jetzige Ebene.
Leseempfehlungen:
-"Niemand zu Hause", http://www.amazon.de/Niemand-Hause-Vom-Glauben-Klarheit/dp/3933496721
-"Erleuchtet - und was jetzt?", http://www.amazon.de/Erleuchtet-Freuden-Leiden-befreiten-Bewusstseins/dp/3778781952
Happy reading! :-)
Jetzt stimme ich dir zu. Diese Erklärung deinerseits war sehr verständlich für mich. Und du hast auch hier wieder recht. Das dann kein ICH mehr existiert hatte ich vergessen.
Was mich noch grübel lässt ist deine Aussage: "Schlimm ist es, Zustand und Ebene zu verwechseln. Und schlimm ist Ignoranz/Arroganz."
War das auf mich bezogen oder eine allgemeine Aussage? Hab mir meinen Post gerade nochmal durchgelesen und dabei gemerkt, dass dieser wohl so ignorant/arogant verstanden werden kann. Das ist meine Meinung und nicht immer meine persönliche Erfahrung, was für mich aber nicht schlimm ist. Ich selbst habe noch viel vor mir, viel zu lernen. Hast du die Erfahrung gemacht, es selbst gemacht haben zu müssen, und zwar immer wieder um Erfahrung zu sammeln, um es RICHTIG zu verstehen? Ich habe bisher noch nie ohne Erfahrung gelernt. Aber ich bin der Meinung, dass es möglich ist.
Meine Frau hat mir erst vor kurzem anschaulich beigebracht, dass Reflektion wichtig ist um zu lernen. Also tue ich das jetzt, weil ich es als richtig für mich erkannt habe.
So denn freu ich mich auf deine weiteren lehrreichen Ausführungen und Postings. Was Softwareentwicklung angeht schaue ich seit einiger Zeit zu deinen Ausführungen auf.
@Rainer: Nein, keine Sorge, war nicht pers. gemeint.
Ignoranz und Arroganz interessieren sich so ganz allgemein nicht für den Prä/Trans-Trugschluss (allerdings aus unterschiedl Gründen). Und das ist übel, weil sie dadurch sich und andere behindern, weiter aufzusteigen.
Reflektion ist sehr wichtig, weil sonst Wissen intuitiv/implizit bleibt. Das ist nicht schlimm - aber dann kann man nur langsam vorankommen.
Vom kleinen König (http://www.derkleinekoenig.de/) gibt es eine schöne Geschichte mit einer Wippe zum Thema intuitives Wissen: Er will eine Wippe bauen, hat aber nur intuitives Wissen zum Wippen. Da braucht er sehr lang, bis es funktioniert - und am Ende kennt er die Hebelgesetze immer noch nicht. Er kann also wippen - aber eine Wippe nicht systematisch reproduzieren oder an neue Anforderungen anpassen. Dazu müsste er explizite Kenntnis der Hebelgesetze haben.
-Ralf
Nochmal reflektiert. Das habe ich auch schon früher gemacht, aber die Fähigkeit Reflektion als solches nie erkannt. Ich habe es getan, wusste es aber nicht. Nun ja, vielleicht ist auch die Reflektion das, was z.B. deinen Schreibstil, bzw. die dotnetpro.tv ausmacht. Dort tust du es dauernd, für dich selbst reflektieren. Damit kannst du es jedem leicht verständlich machen.
Und jetzt wieder zum Thema:
Also ankommen im Binären Nirvana ist ja irgendwie doch nicht richtig. Denn der Weg ist ja bekanntlich das Ziel. Bewußt handeln ist es ja was wichtig ist. Für Software heißt das doch, dass ich weiß warum und wie ich etwas implementiere. Das kann auch ruhig Intuition sein, denn ich denke dass irgendwann das Bewußte in Intuition übergeht. Und ob ich mich da auf einer Ebene 5 oder 9 bewege spielt dabei keine Rolle, wenn es den Anforderungen genügt, oder? Aber vielleicht liegt das auch an der Ebenenaufteilung selbst. Du hast ja bereits erwäht, dass es hier auch andere Dartstellungen geben kann. Was habe ich aus dieser Diskussion dann gelernt?
Wenn ich etwas implementieren will mache ich mir Gedanken darüber was und wie ich die Anforderung auf dem mir bekannten, best möglichen Weg implementiere um den Anforderungen gerecht zu werden (Anforderungen jedweder Art und Größe)Aber gibt es so etwas wie die Erleuchtung überhaupt in der SW um meine Metapher mit dem Buddhismus weiter zu spinnen? Was sind die Maxime nach denen wir dann Entwickeln? ich weiß da gibt es viele. Wirtschaftlichkeit, Kundenzufriedenheit, Wartbarkeit, Erweiterbarkeit, Fehlerfreiheit, Testbarkeit ... und die Komponentenorientierung bietet uns diese Möglichkeit. In diesem Fall ist das durch Jahrelange Erfahrung oder Forschung/Wissenschaftliches Arbeiten entstanden, so meine Vermutung. Was aber wäre gewesen, wenn jemand gekommen wäre und hätte uns dieses Konzept auf den Tisch gelegt und gesagt: So muss Software Entwickelt werden. Das habe ich mir ausgedacht und in den Bereichen Testbarkeit, Wartbarkeit, Skalierbarkeit und und und hat das diesen und jenen Vorteil? Wäre es nicht genauso richtig gewesen, ohne entsprechende Erfahrung gehabt zu haben. Wichtig ist lediglich die plausible Art es zu erläutern. Muss es immer wissenschaftlich beweisbar sein, um es auf Richtigkeit zu prüfen? Vielleicht beim Entwickeln schon, weil sie ja auch wissenschaftlichen Erkenntnissen beruht. Vielleicht aber auch nicht. Ich denke wir halten so an dem Beweisbaren fest, weil es ein Bestandteil unserer Gesellschaft ist. Angenommen du entwickelst eine Komponenten, ist es dann für denjenigen der sie benutzt wichtig zu verstehen wie sie innendrinnen funktioniert? nein. Derjenige muss nur verstehen, warum es die Komponenten gibt und wie die Interfaces zu benutzen sind. Dafür gibt es ja den Contract. Diesen muss er sehr wohl kennen. Die Erfahrung davor die du gemacht hast, die Komponente zu erstellen benötigt er nicht. Aber er versteht anhand deiner Implementation die Zusammenhänge und weiß jetzt, da er ja reflektiert und nachdenkt, warum das so gemacht werden muss. In dem Moment, in dem du ihm die fertige Komponente in die Hand drückst und ihm erklärst, wie sie funktioniert, hat er genug "Erfahrung" gesammelt und damit zu arbeiten, vorausgesetzt er kann sich alles merken, was du ihm erzählst und er versteht alles. Du musst es ihm dann kein 2,3 oder 1000 mal erzählen.
Ich habe über die Aussage Zustand != Ebene nachgedacht. Und ich weiß jetzt nicht genau ob ich dir Recht geben soll. Aber für mich stellt sich jetzt die Frage: Wenn ich einen Zustand dauerhaft einnehme befinde ich mich dann nicht auf dieser "Zustandsebene"? Wichtig ist doch dann, so habe ich das jetzt aus den Büchern und deiner Aussage verstanden, sich dessen stets bewußt zu sein, wobei dies durch häufiges wiederkehren in Intuition übergeht und du nicht mehr nachdenken musst etwas zu tun, aber es jederzeit weißt, warum, wenn dich jemand danach fragt. Und ob eine Ebene übersprungen werden kann glaube ich auch nicht! Das fand ich ja an deiner Erklärung im Post so gut. Ich habe Zustand immer mit dem Prädikat "dauerhaft" ausgezeichnet und daher ist es für mich das gleiche wie eine Ebene.
Last but not least: Wenn ich mir den Zustand der Entwicklung, die du für die Komponente gebraucht hast bewußt mache, also verstehe, was du mir erklärst, muss ich dann die gleiche Komponente noch einmal entwickeln um auf die gleiche Ebene wie du zu kommen?
Wie dem auch sei. Einiges wieder an neuen Gedanken zum aufarbeiten.
Vielen Dank für die Buchtipps, werde ich mir anschauen.
Rainer
@Rainer: Zustand vs Ebene: Zwei Worte, die ich nicht für synonym halte. Und auch wenn ein Zustand länger dauern kann, ist er für mich immer mit einer Zeitkomponente versehen, also letztlich nicht von Dauer.
Eine Ebene ist dann erstmal etwas, auf der ich sein kann und dabei einen passenden Zustand habe. Wenn ich aus dem aber wieder rausfalle... dann habe ich die Ebene nicht dauerhaft erreicht. Ich bin dann halt noch nicht auf der Entwicklungsstufe - sondern nur mal hochgesprungen.
Vergleich zum Sport: Du läufst noch nicht 11 sec/100 m. Du läufst 14 oder 15 sec. Aber an einem total guten Tag... da läufst du plötzlich mal 11 sec. Hast du dann die Ebene "schneller als 12 sec" erreicht? Ja, in einem Zustand - der morgen aber wieder vorbei ist. Aber du warst mal da, hast da mal gekostet. Dann trainierst du weiter - und irgendwann läufst du zuverlässig immer unter 12 sec. Dann bist du auf der Ebene angekommen. Dann würde ich das nicht mehr Zustand nennen.
Das mit der Intuition kann leicht ein Prä/Trans-Trugschluss sein. Was die Leute heute nicht alles aus Intuition tun - und am Ende auf die Nase fallen, z.B. investieren: http://www.zeit.de/zeit-wissen/2007/03/Neuro-Finanz
Wenn du auf einer Ebene endgültig angekommen bist, dann beherrschst du die Dinge dieser und darunter liegender Ebenen vielleicht eher intuitiv. Aber nur weil du etwas intuitiv entscheidest, heißt das umgekehrt nicht, dass es richtig entschieden ist. Der Meister mag intuitiv entscheiden, kann aber am Ende immer klar machen, warum das so richtig war. Das ist trans-konventionell. Der Lehrling entscheidet auch intuitiv, auch mal richtig - aber mit der Erklärung hapert es dann eher.
Also Vorsicht mit Intuition. Das merke ich auch immer wieder bei meiner Arbeit. Grad mein aktueller Artikel in der dotnetpro dreht sich darum: da hatte ich etwas eher intuitiv entschieden... musste mich am Ende aber sehr anstrengen, dafür eine Rechtfertigung zu finden.
Musst du eine Komponente selbst entwickeln, um auf deren Ebene anzukommen? Ja. Du musst selbst die Fragen beantworten, die das Problem an dich stellt. Ob du auf einer Ebene bist, kannst du wohl relativ leicht feststellen, wenn du die Technologien und Konzepte und Lösungen auf dieser Ebene jmd erklärst. Geht dir die Erklärung leicht von der Hand? Kannst du ihr Wendungen hinzufügen, die du vorher nicht gehört hattest? Kannst du Fragen dazu beantworten?
Erklärungen bekommen ist wie, ein Buch übers Schwimmen zu lesen. Nett - aber ersetzt die eigene Übung nicht.
-Ralf
Na super, jetzt sind wir beide fast einer Meinung, nur das du es mir jetzt noch einmal für mich verständlich erklären konntest.
1. Durch verschiedene Zustände erreichst du eine Ebene, wenn diese Zustände dauerhaft sind und bleiben. Ansonsten wird diese Ebene wieder verlasssen.
2. Intuition, das habe ich ja auch nachgebessert, ist nur dann hilfreich, wenn du vermitteln, eben reflektieren kannst, was du tust und warum du es tust.
3. Das mit der Übung und mit der letztendlichen Erfahrung ist mir mit deinen zwei Beispielen nun schlussendlich klar geworden.
Habe in der Zwischenzeit ein bischen in deinen alten Posts über Software-/Philosophie gelesen. Und habe daraufhin schon gemerkt, dass ich in meiner Erklärung einige Denkfehler hatte. Danke nochmal für die ausfürhliche Antwort.
Ich für meinen Teil kann dir jetzt guten Gewissens zustimmen, dass ich die Erfahrung machen sollte, um zu wissen wie es funktioniert. Dann kann ich es auch weitergeben und erklären.
Nun möchte ich zu guter letzt aber dennoch die Frage in den Raum werfen. Kann Wissen nur durch Erfahrung bestehen? Kann Wissen nicht auch durch Denken und Erkennen entstehen? Für den Bereich der Wissenschaftlichen Abhandlung der Westlichen Welt und in unserem jetzt speziellen Fall Softwareentwicklung verstehe ich das und stimme dir zu. Kann aber Wissen nicht auch ohne diese Nachweisbarkeit entstehen, muss ich (im übertragenen Sinn auf ein anderes nicht wissenschaftliches Gebiet) erst einmal im Wasser gewesen sein um zu schwimmen um zu Wissen wie es funktioniert, oder danach es anzuwenden? Du sprichst jedem, der es vielleicht doch könnte die Fähigkeit ab es tun zu können. So wie mit der Hummel, die laut unseren Naturgesetzten nicht fliegen könnte ... und sie tut es ja bekanntlich doch.
Und nochmal ein Zitat aus dem Eintrag: "Bewusstseinsstufen sind wie Brillen, die wir nicht abnehmen können."
Die Erklärung habe ich letztens auch in "Sophies Welt" gehört. Die Brille ist dabei aber dennoch nur ein Hilfsmittel zum Sehen und Erkennen. Ist eigentlich nicht letztendlich das Erkennen ein Auge zu sein selbst der Erstrebenswerte Zustand? Das Auge kann sich nur durch den Spiegel sehen, durch Reflektionen. Es sind aber noch immer Reflektionen, nicht das wahre selbst. Reicht das dem Auge um zu Erkennen was es selbst ist? Können wir ein Bewußtsein erlangen um uns aus dieser Dualität zu befreien?
@Rainer: Kann Wissen nur durch Erfahrung entstehen? Ich würde sagen, ja. Alles andere ist Spekulation. (A priori Wissen nehme ich mal aus - sofern es das gibt.)
Am Ende gibt es ja auch kein Wissen, sondern immer nur Modelle/Hypothesen. (Wenn wir mal mathematische Beweise ausklammern.)
Wissen klingt so nach Endgültigkeit oder Wahrheit. Aber beides gibt es nicht. (Soviel zu meiner post-modernen Haltung ;-)
Alles Leben ist also im Vorläufigen. Nicht nur die Softwareentwicklung. Deine Beziehung ist vorläufig, dein Job, die Marktwirtschaft. Heirat oder Hausbau sind menschliche-allzu-menschliche Versuche, in diese ganze Vorläufigkeit "Taschen der Konstanz einzunähen". Manchmal funktioniert das - manchmal nicht.
Und warum ist alles vorläufig? Weil wir so schlecht im Erkennen sind. Wir nehmen die angenommene real existierende und von uns unabhängige Realität so schlecht wahr, dass wir immer wieder prüfen müssen (handeln, Feedback sammeln), ob unser Modell von ihr (noch) stimmt.
Nachweisbarkeit: Hier rührst du an der Frage, was wir denn als "Wissen" anerkennen. Nur das, was "die wissenschaftliche Methode" uns vermittelt oder gibt es auch "Glaubensgewissheit"? Letztlich kann es jeder halten, wie er will. Manches Wissen lässt sich nur einfacher anderen vermitteln.
Wissen ist ja immer eine Beschreibung von Wirklichkeit. Wie lassen ich "die Welt" auf mich wirken. Da kann jeder seine eigene Wirkung wählen. Nur er darf dann nicht erwarten, dass andere dieselbe Wirkung auch haben wollen.
In "Nachweisbarkeit" schwingt nun aber mit, dass nicht nur einer, sondern auch andere etwas wissen sollen. Dazu gehört letztlich, dass nicht nur einer, sondern eben auch die anderen es erfahren können müssen. Alles andere ist eine Glaubenssache.
Ich spreche niemandem ab, schwimmen lernen zu können. Aber wenn noch niemand geschwommen ist, ist es nur eine Hypothese, ob man es überhaupt kann. Das weiß man erst, wenn es min. einer geschafft hat. Anschließend weiß man nur, dass es irgendwie überhaupt geht. Das bedeutet nicht, dass es jeder kann. Das kann man ja nicht durch Induktion beweisen. Also muss es jeder wieder selbst probieren. Vorbereitung mit einem Schwimmlehrbuch ist dabei nett - aber nicht ausreichend.
-Ralf
Kommentar veröffentlichen