Erfolgreiches Software Engineering erfordert mehr als nur mittelmäßig gut ausgebildete Programmierer und Tester


In der Computerwoche vom 30.8.2016 liest man:

Kurz- und mittelfristig erföffnet die Digitalisierung Softwareentwicklern gute Aussichten: Sie werden für die Ablösung der Altsysteme gebraucht. Um sie voranzutreiben, braucht es Softwareentwickler. Besonders im deutschsprachigen Raum ist der Beruf des Programmierers aber nicht so angesagt wie er sein sollte.

Meine Meinung dazu:

  • Nur wenige Programmierer sind das, was ich als kompetente Software-Entwickler bezeichnen würde.
     
  • Ihren Chefs scheint das selten klar zu sein.

    Zudem glaubt man allzu oft, als Software-Entwickler schlecht ausgebildete Programmierer & Tester einsetzen zu können (um so Geld zu sparen).
     
  • Diese Fehleinschätzung wird sich rächen.
     
  • Erste Anzeichen dafür, dass ich recht haben könnte, gibt es schon.

 
Mein Eindruck:

Wenn man heute von Programmierern spricht, sind damit nicht selten nur noch Leute gemeint, die mehr oder weniger kompetent an Code rumfummeln können und SCRUM für ein Synonym modernster Projektabwicklungsmethodik halten.

Für die Beseitigung kleiner Fehler mag das ja gerade noch ausreichen. Komplexe unternehmens­kritische Legacy Software auf neue Technologie zu migrieren reicht es aber keinesfalls. Was dabei herauskommt sind Desaster wie das in Kalifornien: Beim Versuch, das Payroll System des Staates neu zu implementieren hat man gleich zwei Mal Schiffbruch erlitten. Der zweite Auftragnehmer (immerhin SAP) musste sich schließlich bereit erklären, Schadenersatz in Höhe von 59 Millionen Dollar zu zahlen und auf weitere 23 Millionen Dollar eigener Forderungen zu verzichten.

Wie wenig kompetent Software-Entwicklungs-Teams gelegentlich sein können, zeigt auch ein Beispiel aus 2012.

2011 wurden nicht weniger als zehn ähnlich umfangreiche Projektkatastrophen bekannt. Alle hatten ERP Software zum Gegenstand, Software also, welche die Existenz der Unter­nehmen, die sie einsetzen, gefährden kann, wenn sie nicht richtig funktioniert.

Besonders lehrreich ist der Fall in Großbritannien, wo ein Schaden von 11 Mrd. Pfund entstand u.A. deswegen, weil die mit der Implementierung des nationalen Verwaltungssystems für Patientendaten beauftragten Software-Entwickler (in diesem Fall CSC) bis zuletzt nicht erkannten, dass sie mit der Realisierung der Software überfordert waren: [B].

Über falsch verstandene “Agile” Methodik


Wer mich kennt der weiß:

Ich bin ein erklärter Gegner der im Agile Manifesto postulierten Methodik und der daraus entstandenen — völlig ungeeigneten — Software-Entwicklungs-Modelle, für die heute SCRUM schon fast als repräsentativ gilt.

Am deutlichsten habe ich meine Warnung vor solch verwerflichen Formen von Agile wohl zusammengefasst auf den beiden Seiten

Man sollte daraus nun aber nicht schließen, dass ich ein Gegner heute notwendig gewordener Agilität wäre.

Ganz im Gegenteil: Mir ist klar, dass spätestens ab der Jahrtausendwende agiles Vorgehen unverzichtbar geworden ist — die im Manifesto vorgeschlagene Lösung allerdings kann nur ins Verderben führen (denn sie ist undurchdacht und beispiellos naiv).

Meine Ansicht darüber, wie Agilität verstanden und gelebt werden sollte, ist definiert auf den beiden Seiten:

Um zu zeigen, dass ich keineswegs der einzige bin, der “Agile” und SCRUM für absolut ungeeignet — ja sogar gefährlich — hält, seien hier Links hin zu Meinungen Dritter aufgelistet, die ebenso denken wie ich und die aus eigener negativer Erfahrung heraus zu dieser Einstellung kamen:

  • Gartner fand heraus …
     
  • Michael O. Church — heute bei Google — sah durch Umstieg auf SCRUM ein schon börsen-notiertes Startup-Unternehmen zugrunde gehen. Er schreibt wörtlich: “This shit is toxic, it needs to die yesterday.”
     
  • Erik Meijer, ein mehrfach preisgekrönter Fachmann für Software-Entwicklung, nennt SCRUM ein “Krebsgeschwür”.

Weitere Meinungen:

Historisch gesehen, gilt:

Die extrem bürokratisch angelegten Vorgehensmodelle, die

  • zunächst in den USA durchs DoD (Department of Defence) zur Pflicht gemacht wurden,
  • dann aber — in Nachahmung davon — auch in Deutschland als sog. V-Modell (entwickelt von der IABG) sogar Behördenstandard wurden,

mussten irgendwann zu einer Gegenreaktion, zu einem Befreiungsschlag führen. Er kam in Form der Agilen Bewegung, war aber nicht durch entspre­chende Forschung unterstützt, und hat daher zu einem geradezu lächer­lichen Modell geführt, dessen Aushängeschild sich SCRUM nennt und fast schon als verdammenswert einzustufen ist).

Erst nach 2000 wurde einigen wenigen klar, wie ernst man die Gefahren dieser neue Bewegung nehmen muss. Weltweit anerkannte Methodiker des Software-Engineerings, die ihre Stimme hätten erheben können, waren da aber just schon alle aus dem aktiven Berufsleben ausgeschieden.

Nur so ist erklärbar, dass diesem ganzen Unsinn bis heute kein Einhalt geboten wurde …

Erfahrene Software-Entwickler wissen: Um agil zu sein, reicht es völlig

  • das klassische Wasserfallmodell spiralförmig anzuwenden (sprich: zuzu­geben, dass jede seiner Phasen erst zu Projektende abgeschlossen sein kann)
  • und allzu bürokratische Regeln des V-Modells einfach zu ignorieren (es also projektspezifisch zu verschlanken).

Natürlich wird, damit der Auftragnehmer auch im Kontext von Festpreisprojekten nicht ungebührend benachteiligt wird, jede Abänderung einer durch beide Parteien als zunächst fertig akzeptierten Version des Pflichtenheftes einer geeigneten Vertragserweiterung bedürfen (Change Management).
 

Fehlende Software-Qualität kann auch große Unternehmen gefährlich stolpern lassen!


Dass fehlende Qualität von Software ein Unternehmen in Krisen führen kann, bestätigt sich auf jeden Fall dann, wenn anhaltende Probleme mit einen unter­nehmenskritischen neuen System den CFO zu einer Gewinnwarnung zwingen und so auch die Aktionäre beunruhigen.

Sie glauben nicht, dass so was passiert? Nun, hier ist ein Beispiel:

Wie die Computerwoche berichtet, droht das misslungene neue Computersystem “New Forwarding Environment” (NFE) die Deutsche Post im Frachtgeschäft um Jahre zurückzuwerfen.

Deteils finden sich auf FinanzNachrichten.de in einer Meldung vom 29.10.2015:
 

    Larry Rosen, der Finanzchef der deutschen Post, erklärt, NFE sei zu fehleranfällig und müsse wohl ersetzt werden, was Jahre dauern könne, denn eine neue, weniger komplexe Lösung stehe kurzfristig nicht zur Verfügung.

    Man überlege nun, schrittweise neue Komponenten zu integrieren und habe Rückstellungen in Höhe von 37 Millionen Euro gebildet für Ausgaben zur erwarteten Rückabwicklung des Systems in den bereits umgestellten Pilotländern.

    Der Bonner Konzern schätze die Wahrscheinlichkeit, aus dem derzeitigen System positive Effekte erzielen zu können, als sehr gering ein und habe deshalb auch Abschreibungen in Höhe von 309 Mio. Euro vorgenommen.

    Die bereits nach dem zweiten Quartal 2015 schon einmal korrigierte Prognose sei nun nicht mehr zu halten.

 

Nachdenklich macht: NFE basiert auf Software von SAP und wurde mit IBM Global Business Services als Implementierungspartner umgesetzt.

Da sollte man sich schon fragen, wie es zu einem solchem Unglück kommen konnte.

Eines dürfte klar sein:

Obgleich zu akzeptabler Software-Qualität weit mehr gehört als nur die Abwesen­heit von Programmierfehlern, wird sie doch (vom Software-Lieferanten) gerne auf genau solche reduziert gesehen. Dem Auftraggeber fällt das zunächst gar nicht auf.

Doch können denn wirklich nur Programmierfehler so ein Desaster verursachen, wenn das System auf Code beruht, den SAP und IBM entwickelt haben (Firmen also, von denen man erwartet, dass sie kompetentes Personal einsetzen)?

Meine etwa 30-jährige Erfahrung mit Software-Entwicklung sagt mir, dass ein System, dessen Anforderungen vor Beginn der Programmierung genau und vollständig schriftlich spezifiziert und entsprechend gründlich durchdacht worden sind, von erfahrenen Programmierern auf keinen Fall derart verkorkst werden kann, dass es nicht gelingt, alles wesentliche Fehlverhalten innerhalb weniger Monate, wenn nicht Wochen, beseitigen zu können.

An was aber mag es denn dann liegen, dass selbst weltweit bekannte Software-Lieferanten wie IBM — solche, denen man größtmögliche Erfahrung unterstellt — ein System abliefern, welches seine Anwender und Betreiber als kaum nutzbar, auf jeden Fall aber als nicht länger tragbar einstufen?

Mein Verdacht: Man wird wohl versucht haben, nach dem Agilen Manifest zu arbeiten — nach dem Vorgehensmodell also, das seit der Jahrtausendwende unter dem Label “Agile” hochgelobt wird, weil junge Entwickler sich nicht mehr die Mühe machen wollen, die klassischen Verfahren des Software-Engineerings wirklich zu verstehen und der inzwischen neu hinzugekommenen Notwendigkeit, maximal flexibel zu sein, erfolgreich anzupassen — auch und gerade unter der Neben­bedingung, dass heute fast alle Entwicklungsaufträge zum Festpreis vergeben werden.

Wenn die Deutsche Post jetzt plant — und sich sogar gezwungen sieht — “eher evolu­tionär” vorzugehen (wie Rosen sich ausdrückt), klingt mir das schon fast nach einer Wiederholung des von mir vermuteten Fehlers.

Will man wirklich riskieren, dass ich recht habe? Will man nicht zuerst über die Ursachen des Mißerfolgs nachzudenken?

Oder will man einfach nicht einsehen, dass der klassische Weg, Software zu ent­wickeln, eher Erfolg garantiert als SCRUM-artig gestaltete Prozesse in Kombination mit dem blinden Glauben an die Effektivität der allzu naiven Prinzipien des Agilen Manifests?

Ist uns denn nicht bewusst, dass Agile, SCRUM und dieser ganze verhängnisvolle, viel zu wenig durchdachte Trend auf eine kleine Gruppe von Wartungsprogram­mieren zurückgehen, die dachten zu wissen, wie man wirklich große Software-Entwicklungsprojekte so durchführt, dass (fast) nichts mehr schief gehen kann?

Wer glaubt, man könne die Wahl des Prozessmodells zur Entwicklung einer umfangreichen IT-Lösung einfach der Mode oder nur an ihren Code denkenden Programmierern überlassen, der irrt gewaltig.

Dem CIO der Deutschen Post jedenfalls kann man nur raten, die Ursachen seines Desasters genau zu identifizieren.

Versäumt er das, könnte die Deutsche Post in einer eher noch folgenreicheren IT-Sackgasse landen. Ob es dann noch reichen würde, einfach nur eine Gewinn­warnung herauszugeben, kann bezweifelt werden.
 

Softwarequalität — erwarte sie nie vom Auftragnehmer (!)


Im Dzone Guide to Software Quality and Software Agility, Edition 2015 findet sich auf den Seiten 4-5 das Ergebnis einer Umfrage unter 600 IT Professionals (von denen die meisten im Umfeld der Implementierung Java-basierter Enterprise Applikationen arbeiten dürften: denn auf dieses Umfeld konzentriert sich Dzone).

Und dieses Ergebnis ist erschreckend (in Englisch gehaltene Aussagen sind Zitate aus dem Bericht):


    DZone surveyed more than 600 IT professionals for our Guide to Code Quality and Software Agility to discover how organizations should prioritize various quality metrics as they mature, and to reveal how the types of software they produce inf luence their testing strategies.

    Starting with the basics, we asked respondents whether their team does testing at all. 87% said they do, leaving 13% who don’t. 95% of respondents said they believe that testing is necessary on all the software they develop, meaning 8% of respondents don’t do testing, but believe they should.

 
Man kann dieses Umfrageergebnis auch so lesen:


    13% aller Entwickler testen gar nicht, was sie implementiert haben.

    Einer von 20 denkt sogar, Test sei überflüssig (!).

 
Wen will es bei solcher Einstellung noch wundern, dass Software häufig deutlich zu schlechte Qualität hat?

Die Auftraggeber bezahlen das mit zu hohen Wartungskosten (und hohem Risiko) über den gesamten Lebenszyklus der Anwendung hinweg.

Erschreckend ist, dass selbst Entwickler, die wissen, dass Test notwendig ist, ihn — je nach Unternehmen mehr oder weniger — viel zu früh beenden (oft sogar im vollen Bewusstsein, dass bisher durchgeführter Test nicht ausreicht).

Dies belegen folgende Aussagen des Umfrageergebnisses:


    The Definition of Done Varies Significantly Among Organisations:

    The most basic definition of done for software products is also the most common for respondents:

    79% say its when all code compiles and builds for all platforms.

    Other common answers were [ Prozentzahl auf jeweils ein spezifisches Unternehmen bezogen? ]:

    • Features reviewed and accepted by Product Owner (65%),
    • New features are system-tested (59%),
    • Acceptance/story tests are written and passing (52%).

    We also asked whether respondents had ever had deadlines in their current product team that caused them to release with less testing than they thought was necessary. 72% said yes.

 
Es wundert mich immer wieder, wie wenig Auftraggeber versuchen zu erzwingen, dass sie für ihr Geld auch wirklich Qualität bekommen. Sind Einkäufer auch großer Unternehmen derart inkompetent? Oder gibt man ihnen einfach nur falsche Zielvorgaben?

Zu ungenaue Dokumentation von Software-Anforderungen kann enorme Schäden verursachen


Anforderungen an unternehmenskritische Software müssen schriftlich, genau und vollständig dokumentiert sein.

Welch gewaltiger Schaden entstehen kann, wenn man das nicht beherzigt, zeigen die folgenden beiden Beispiele:

  • The Mars Climate Orbiter space probe failed to land on Sep 23, 1999, because its thruster control software was based on English units while the team responsible for adjusting its trajectory was using the metric system!
     
  • A few months later, the Mars Polar Lander also experienced a setback during its landing. It was still 40 metres above its final landing point when its feet deployed, as expected, but the software interpreted it as an imminent event. As a result, the computer shut down the descent engines, leading to an abrupt crash and total loss of both mission and hardware. System engineers had advised the software developers to not rely on the transient signal from the legs of the lander as they were deploying but, apparently, they failed to document this information in the software specifications.

Quelle: Software Quality Issues, 22 Jun 2015, by Claude Y. Laporte

Beide Beispiele zeigen klar und deutlich, dass keine Anforderung

  • als selbstverständlich gelten
  • oder auch nur undokumentiert bleiben darf.

Es reicht auf keinen Fall, Anforderungen nur mündlich zu kommunizieren — schon allein deswegen nicht, weil später hinzukommende Tester sie dann ja nicht kennen und deswegen auch nicht gezielt verifi­zie­ren werden.
 

Schrödingers Katze: Warum das Gleichnis hinkt


Schrödingers Katze dürfte das am meisten missverstandene Gleichnis in der Welt der Physik überhaupt sein.

Kaum ein Sachbuch und kaum ein Physiker, der es zu erklären versucht, erklärt es wirklich richtig. Schrödinger selbst fiel das auch auf, und so klagte er einmal:

    Ich mag sie nicht, und es tut mir leid, dass ich jemals etwas mit ihr
    zu tun hatte.

Warum aber hinkt das Beispiel denn nun? Und warum gibt es den Überlagerungs­zustand — wenn man ihn wörtlich nimmt — nicht wirklich?

Betrachten wir dazu ein Photon, dessen Polarisierung man messen möchte.

Solche Messung kann nur erfolgen mit Hilfe einer Messapparatur, die ausschließ­lich Fragen stellen kann, die das Photon mit JA oder NEIN beantwortet.

Wird Polarisierung gemessen, so bedeutet die Messung stets nur

  • das Auswählen einer Richtung R (durch Justierung des Messgeräts M)
  • und dann das Stellen der Frage M(R) = Liebes Photon: Bist du in Richtung R polarisiert?

Wenn die Messapparatur das Photon durchlässt (also in Richtung R polarisiert), interpretiert man das als Antwort JA, ansonsten aber als Antwort NEIN.

Was aber bedeutet so ein JA oder NEIN?

  • Das JA bedeutet: Nach der Messung ist das Photon in Richtung R polarisiert. Ob, und gegebenenfalls wie, das Photon vor der Messung polarisiert war wissen wir dennoch nicht — mit einer kleinen Ausnahme allerdings: Wir können dann sicher sein, dass es vorher nicht senkrecht zu R polarisiert war.
     
  • Das NEIN bedeutet: Ob, und wenn ja in welcher Richtung, das Photon vor der Messung polarisiert war, wissen wir nicht — die Antwort sagt uns nur, dass es nicht in Richtung R polarisiert gewesen sein kann.

Ganz gleich also, welche der beiden Antworten man als Physiker erhält: Für den Polarisationszustand des Photons vor der Messung gibt es weiter ebenso viele Alternativen wie es reelle Zahlen zwischen 0 und 1 gibt: unendlich viele.

Und genau deswegen versteht man unter dem sog. Überlagerungszustand, in dem das Photon sich vor der Messung befindet, eben NICHT zwei Zustände, die gleichzeitig vorliegen.

Wirklich gemeint mit dem Begriff ist einfach nur die Tatsache, dass das Mess­ergebnis uns so gut wie nichts über den Zustand des Photons unmittelbar vor der Messung sagen kann.

Dass dem so ist, mag beim Photon erstaunen, da wir im Fall der Katze ja nicht erwarten würden, dass erst unser Hineinsehen in die Box das Tier in den Zustand versetzt, in dem wir es dann vorfinden.
 

Wie oft — und wie dramatisch — Software-Tester versagen


Dass es wirklich höchste Zeit wird, auch die Effektivität von Software-Testern systematisch zu kontrollieren, zeigt eine ganz unglaubliche Sicherheitslücke, die im Februar 2015 in gleich mehreren Tausend per Internet zugänglicher Anwendun­gen entdeckt wurde:

Wie die Computerwoche schrieb, handelte es sich um Konfigurationsfehler die zur Folge hatten, dass — im Prinzip wenigstens — jeder Internet-Nutzer mehrere Millionen Kundendaten nach Name, Adresse, E-Mail und Kreditkartennummer im Internet nicht nur abrufen, sondern auch manipulieren konnte.

Von den zahlreichen Entwicklern dieser vielen Anwendungen war ganz offensicht­lich keinerlei ernsthafter Sicherheitstest durchgeführt worden.

Will da noch jemand behaupten, sie hätten professionell genug gearbeitet?

Und ganz offensichtlich hat auch niemand unter den Verantwortlichen ernsthaft ge­prüft, wie vollständig der Test, für den sie bezahlt hatten, denn nun eigentlich war.

Glaubt die Software-Industrie wirklich, sich derart dilettantisches Vorgehen noch lange leisten zu können?
 

Verständlich dargestelltes Wissen zu Theoretischer Physik, Quantenphysik und Kosmologie


Wer — beispielsweise als Schüler oder als angehender Student der Physik — an gut verständlich dargestelltem Grundwissen zu Quantenphysik und Kosmologie interessiert ist, dem empfehle ich die Lektüre einiger der Kurzartikel hinter den Links auf Seite Interessantes zur Physik.

Es werden dort Konzepte diskutiert, aber keinerlei Formeln oder deren Herleitung.
 

Wie man als CIO Budget für Softwaretest optimal einsetzt


Projekte, die eine Modernisierung unternehmenskritischer Software-Applikationen großer Unternehmen zum Ziel haben, werden größer und größer und verursachen heute Kosten, die gar nicht mehr so selten 3-stellige Millionenhöhe erreichen.

Einen ganz beträchtlichen Teil solcher Ausgaben verursacht der Test der neuen Lösungen: Typischerweise arbeitet daran ein großes Team (in Fällen, die ich zwischen 2003 und 2010 beobachten konnte, waren es bis zu 50 Personen über Jahre hinweg).

Natürlich versucht der CIO des Auftraggebers dann hin und wieder, kosten­günstigere Dienstleister zu finden. Das gängige Verfahren: Es erfolgt eine neue Ausschreibung der Testaufgabe mit dem Ziel, zu prüfen,

  • ob der gegenwärtige Dienstleister nicht allzu teuer oder zu wenig kreativ geworden ist (z.B. deswegen, weil er bestrebt sein wird, mit der Zeit weniger erfahrenes, für ihn billigeres Personal einzusetzen)
     
  • oder ob es konkurrierende Anbieter gibt, die ihn deutlich zu unterbieten in der Lage sind, Offshore-Anbieter etwa.

Sehr oft steht am Ende einer solchen Ausschreibung der Austausch des Anbieters, d.h. der Austausch des gesamtem, großen Teams von Testern und Testmanager.

Das aber kann gefährlich sein, denn

  • erstens geht dabei eine große Menge von Knowhow verloren (die neuen Tester müssen sich ja erst wieder mit der zu testenden Applikationslogik bekannt machen)
     
  • und zweitens ist zunächst noch völlig offen, wie effektiv das neue Team denn nun wirklich arbeiten wird.

Mit anderen Worten:

Die Wahrscheinlichkeit, dass der Befreiungsschlag gelingt, ist ebenso groß wie die Wahrscheinlichkeit, dass er misslingt. Rechnet man die Kosten der notwendigen Einarbeitung des neuen Teams hinzu — Kosten also, die gar nicht anfielen, wenn man beim alten Dienstleister geblieben wäre —, so ist die Wahrschein­lichkeit, dass solcher Wechsel unterm Strich eher Verlust denn Gewinn bedeutet, ziemlich hoch.

Andererseits:

Das Team über Jahre hinweg einfach arbeiten zu lassen, ohne zu versu­chen, die Effektivität des Dienstleisters zu maximieren, wäre ganz sicher auch nicht richtig.

Was also sollte man tun?

Die naheliegenste Lösung ist folgende:

Sobald absehbar ist, dass ein Testteam über längere Zeit hinweg eine gewisse Größe haben muss, sollte man es aufteilen in zwei etwa gleich große Teams, die

  • unter der Regie zueinander konkurrierender Dienstleister
  • unabhängig voneinander an derselben Testaufgabe arbeiten.
  • Wenigstens eines dieser Teams sollte seine Testwerkzeuge selbst wählen dürfen.

Ihre Effektivität sollte einem strengen Monitoring durch den Auftraggeber unter­liegen, so dass der z.B. alle 6 Monate beiden Teams mitteilen kann, wie effektiv jedes von ihnen im Vergleich zum jeweils anderen gearbeitet hat (Effektivität = Kosten dividiert durch die Summe der Gewichte vom Team aufgedeckter Fehler in den zu testenden Applikationen).

Vorteile dieser Lösung:

  • Keiner der beiden Auftragnehmer kann sich leisten, unerfahrende Leute einzusetzen oder ungeeignetes Werkzeug zu nutzen (denn täte er das, würde sofort erkennbar werden, wie seine Effektivität verglichen mit der seines Konkurrenten zurückgeht).
     
  • Sobald eines der beiden Teams deutlich weniger effizient arbeitet als das andere, sieht man, dass es höchste Zeit wird, es auszutauschen.
     
  • Kosten für den Neuaufbau von Knowhow werden so minimiert, und nie ent­steht eine Situation, in der zu wenig gut eingearbeitete Tester verfügbar sind.
     
  • Schon im jeweils eigenen Interesse wird so jedes Team sich optimale Werk­zeuge aussuchen und wird bestrebt sein, das eigene Vorgehen ständig zu überdenken und effektiver zu gestalten.
     
  • Diese Lösung ist kostenneutral.
     
  • Zudem minimiert sie die Wahrscheinlichkeit, dass gelegentlicher Austausch des Dienstleisters zu einer gravierenden Fehlentscheidung wird.

Man bedenke:

Zu beurteilen, wie effektiv Tester arbeiten, ist anders kaum möglich (denn: Die Zahl beim Test gefundener Fehler hängt ja nicht nur davon ab, wie geschickt die Tester vorgehen, sondern auch davon, wie gut die Entwickler gearbeitet haben). Kurz:

Die oben vorgestellte Lösung scheint der einzige Weg zu sein, über den ein CIO erreichen kann, dass die Gelder, mit denen er den Test finanziert, so wirkungsvoll wie nur irgend möglich eingesetzt sind.
 

Der » Kollaps « der Wellenfunktion: Allzu oft missverstanden!


Selbst weltweit bekannten Physikern und Buchautoren ist oft nicht wirklich klar, was der “Kollaps” der Wellenfunktion — ein Begriff, den die Kopenhagener Gruppe unter Führung von Niels Bohr geprägt hat — denn nun wirklich bedeutet.

So schreibt z.B. Michio Kaku auf Seite 307 seines Buches Die Physik des Unmög­lichen (Rowohlt 2008):


    Wir existieren gleichzeitig als Summe aller denkbaren Zustände: nicht schwanger, schwanger, als Kind, als ältere Frau, als junges Mädchen, als Karrierefrau und so weiter.

 
Aber diese seine Aussage ist natürlich Unsinn. [Denn wäre sie richtig, müsste man ja auch feststellen, dass Schrödingers Katze selbst noch nach dem Öffnen der Box in beiden Zuständen existiere: einmal als tote Katze und zum anderen auch als lebende Katze. Das aber hat auch die Kopenhagener Interpretation niemals so gesehen.]

Dass die unglückliche Wortwahl der Kopenhagener Gruppe — genauer: ihr damals noch allzu lückenhaftes Verständnis dessen, was beim “Kollaps” wirklich vorgeht — den Physikern fast ein ganzes Jahrhundert lang das Verständnis der Quanten­mecha­nik deutlich erschwert hat, zeigt sich nicht nur an Kakus Aussagen, sondern z.B. auch an Einstein, Wheeler, Everett III und an all ihren Zeitgenossen bis hin zu Niels Bohr selbst.

Kaku schreibt auch (Seite 307 unten):


    Wenn Einstein Gäste hatte, zeigte er auf den Mond und fragte: » Gibt es den Mond, weil eine Maus in anschaut? «

 
Und Kaku liefert seine ganz persönliche Antwort auf diese Frage gleich mit, indem er schreibt:
 

    In gewisser Hinsicht könnte die Kopenhagener Schule diese Frage mit einem Ja beantworten.

 
Er bezieht sich damit auf die von Bohr gepredigte Meinung, dass erst der Zusam­men­stoß eines Quantensystems mit einer Messapparatur — sein Zusammenstoß mit dem “Beobachter” also, wie man früher sagte — den Kollaps hervorruft und so das Quantensystem aus einem nicht wahrnehmbaren Überlagerungszustand, der stets nur eine Menge von Möglichkeiten darstellt, in einen sichtbaren, konkreten Zustand versetzt.

Das Missverständnis, dem viele Physiker dann aufsaßen (und dem Kaku sogar heute noch zum Opfer fällt) besteht darin, sich nicht klar zu machen, dass es sich beim “Kollaps” keineswegs um einen bleibenden Kollaps, sondern vielmehr nur um eine Korrektur der Wellenfunktion handelt:

Die Kollision von Messapparatur und beobachtetem Quantensystem nämlich hat Wir­kung, und die besteht darin, dass sich Quanten spontan vereinigen oder zerlegen, d.h. die Natur

  • macht  e i n e  von vielen Möglichkeiten zu Wirklichkeit,

  • verwirft alle anderen

  • und korrigiert dem entsprechend sofort auch die Wellenfunktion des Universums (bzw. des jeweils betrachteten Objekts).

 
Kurz: Der sog “Kollaps” der Wellenfunktion bedeutet nicht, dass sie in sich zusam­menbricht — er bedeutet nur, dass sie sich korrigiert. Und diese neue Version ihrer selbst unterscheidet sich in ihrer Qualität überhaupt nicht von der alten (!).

Wäre das Niels Bohr, Everett III, seinem Doktorvater Archibald Wheeler und all ihren Zeitgenossen schon klar gewesen, wäre es ganz sicher gar nicht erst zu Everetts Viele-Welten-Theorie gekommen.

Sie alle — Everett wohl ausgenommen — haben zwar irgendwie gespürt, dass seine Theorie nicht richtig sein kann, waren aber nicht in der Lage, sie zu ent­kräften.

Bohr hat sich deswegen zu Everetts Theorie überhaupt nicht geäußert — trotz des Dränges von Wheeler, der Everett extra nach Kopenhagen geschickt hatte, damit er Bohr seine Theorie präsentiere und Bohrs Argumente gegen sie erfahre. Weehler selbst war zwei Jahrzehnte lang unentschieden, hat sich dann aber doch explizit davon distanziert: Ohne allerdings sagen zu können, warum Everetts Theorie falsch sein müsse.

FAZIT also: Da für das Konzept “Kollaps der Wellenfunktion” ein Name gewählt worden war, der Konkreteres suggeriert hat als tatsächlich bekannt war, ist dieser Begriff nun schon fast 100 Jahre zu einem wirklichen Stolperstein für alle geworden, die bestrebt sind, die Quantenmechanik wirklich zu verstehen.

Ihnen allen sei gesagt: Der “Kollaps” der Wellenfunktion ist einfach nur ihre Anpassung an eine neu entstandene Situation. Und zu solch neu entstehenden Situation kommt es ständig und überall dort, wo Quanten kollidieren, verschmelzen oder neu entstehen.

Und so wissen wir jetzt ganz sicher: Der Mond, der Einstein seine provozierende Frage stellen ließ, extistiert natürlich auch dann, wenn niemand hinsieht — weder ein Mensch, noch eine Maus.

Das warnende Bauchgefühl aber, welches Einstein, Wheeler und Bohr signalisiert hat, dass der “Kollaps” wohl noch nicht so ganz verstanden sei, scheint heute einer ganzen Reihe von Physikern — Kaku etwa — zu fehlen. Und so hat sich denn auch lange Zeit niemand gefragt, ob man Everetts viele Welten — er selbst nannte sie “relative Zustände” — nicht vielleicht gründlich missverstanden hat.

Ich jedenfalls lehne die Viele-Welten-Interpretation, wie schließlich auch Wheeler, als absolut sinnlos ab: Es gibt kein einziges Argument dafür, dass sie richtig sein könnte.

Everett selbst hat, was erst Bryce DeWitt dann “viele Welten” nannte, stets nur als Möglichkeiten für kommende Zustände unserer Welt gesehen (konzipiert durch die Wellenfunktion des Universums). Leider hat ihn damals niemand so verstanden, da er diese Weltentwürfe “relative Zustände” nannte.

Richtig verstanden wurde Everetts (ungekürzte) Arbeit wohl erst durch Max Tegmark. Siehe Kapitel 8 seines Buches Our Mathematical Universe.