In der CW Nr. 51 vom 20. Dezember 1991, Seite 41, stellte Peter Molzberger* die provozierende These auf, daß Programmierfehler in den meisten Fällen Absicht seien. Es handele sieh nicht um Fehler, sondern um hochintelligente Leistungen unseres Unterbewußten, die einem bestimmten Ziel dienen, ähnlich einem Freudschen Versprecher. Dieser Artikel hat eine breite und intensive Diskussion ausgelöst. Im folgenden bringt Molzberger einige Beispiele aus der Praxis, die seine These stützen.

Ich bin überrascht und erfreut über das Echo, den mein Artikel gefunden hat. Es war beileibe nicht immer Zustimmung, sondern auch Widerspruch. Das ist gut so. Dadurch kommt eine notwendige Diskussion darüber in Gang, ob nicht vorbeugende Methoden der Qualitätssicherung effizienter sein könnten als die nachträgliche Behebung von Fehlern.

Ich möchte diese Diskussion weiter anheizen, indem ich konkrete Beispiele nenne, die mich auf die provozierende Idee gebracht haben, daß Programmierer sich selbst sabotieren. Sie betreffen alle eine Person, meinen Freund Josef Thum, genannt Peps, den brillantesten Programmierer, den ich je kennengelernt habe.

Beispiel 1:

Perfektion im Suff

Das erste Beispiel betrifft eine Erfahrung von Perfektion, Fehlerfreiheit. Peps war noch nicht lange im Berufsleben. Eines Abends hatte er dem Alkohol stark zugesprochen, und im Rausch, mitten in der Nacht, begab er sich an seinen Arbeitsplatz. Er setzte sich an den damals gebräuchlichen Locher und begann ein Cobol-Programm für die Gehaltszahlung direkt in die Karten zu stanzen. Als er fertig war, ließ er die 3000 Lochkarten, ohne jeden Test, auf seinem Schreibtisch liegen und ging nach Hause.

Am nächsten Morgen erschien er nicht zur Arbeit, weil er seinen Rausch ausschlafen mußte. Sein Chef entdeckte das Programm, das terminlich überfällig war, auf Peps' Schreibtisch, stellte fest, daß es ablauffähig war, und gab es in der Annahme, es sei voll ausgetestet, in die Produktion. Peps bekam einen riesigen Schreck, als er das erfuhr.

Aber: Die Gehälter wurden korrekt gezahlt, und es gab niemals eine Reklamation. Peps hatte allerdings hinterher Schwierigkeiten sein eigenes Programm zu lesen, da es ihm nicht vertraut vorkam.

Um jedes Mißverständnis auszuschließen, möchte ich zunächst sagen, daß ich das Verfahren keineswegs für die Praxis empfehlen möchte: Auch mich schaudert bei dem Gedanken. Aber ich habe mir angewöhnt, skurrile Dinge auf eine andere Weise ernst zu nehmen. Jeder Durchbruch von morgen ist im Prinzip auch heute schon sichtbar, aber da wir ihn nicht als solchen erkennen, wirken die mit ihm verbundenen Phänomene auf uns befremdlich. Ich möchte das Erlebnis von Peps daher ausführlicher diskutieren.

Für sich betrachtet ist dies eine Anekdote ohne jede wissenschaftliche Aussagekraft. Ich habe sie nicht einmal selbst erlebt, sondern Peps hat sie mir Jahre später erzählt. Häufig, wenn ich sie in der Vorlesung oder in Seminaren erzählte, regte das die Zuhörer an, ähnliche

Geschichten zu berichten. So sind mir im Laufe der Jahre Dutzende von Erfahrungen von Perfektion berichtet worden. Dabei waren zum Teil Alkohol oder andere Drogen im Spiel. Zum Teil war es einfach eine spontane Erfahrung. Auch das sind Anekdoten, und es gibt kaum je die Gelegenheit, diese Aussage wissenschaftlich auszuwerten. Immerhin zeigten sie mir, daß derartige Erfahrungen weitaus häufiger sind, als ich zu nächst angenommen hatte.

Auch ich habe bereits Erfahrungen in Perfektion gemacht. Ich habe Zustände hoher Kreativität beim Schreiben erlebt. Der Text ist klar und druckreif, und ich mag hinterher kein Wort mehr daran ändern oder hinzufügen. Während des Schreibens ist mir die Sache, über die ich schreibe, absolut klar. Ich bin innerlich sicher, daß das, was mir vor Augen steht, absolut richtig ist.

Auch das ist natürlich für meine Leser kein Beweis. Aber ein Beweis ist da überflüssig, wo persönliches Erleben vorliegt. Ich behaupte, daß auch Sie als Leser gelegentlich Erfahrungen in Perfektion gehabt haben. Es muß nicht unbedingt beim Programmieren oder Schreiben sein. Vielleicht spielen Sie ein Instrument und haben einmal erlebt, wie es ist, wenn nicht Sie spielten, sondern "es Sie spielte".

Bitte gehen Sie in Gedanken in die Tätigkeit, die Sie am liebsten tun und fragen Sie sich, wann Sie ein Erlebnis hatten, das Sie sehr beglückt hat und das Sie nicht so schnell vergessen werden.

Ich behaupte, daß jeder von uns in der Lage ist, Dinge perfekt zu tun. Es gibt Bewußtseinszustände, in denen das Hick-hack unserer konkurrierenden Instanzen offensichtlich ausgeschaltet ist, in denen unser Gehirn störungsfrei und mit extremer Präzision läuft, in denen unsere Arbeit perfekte Ergebnisse liefert: gleichzeitig schnell, zuverlässig und elegant.

Wenn Sie mir bis hierher, aufgrund eigener Erlebnisse, folgen konnten, dann lassen Sie uns ein paar naheliegende Schlußfolgerungen ziehen.

Folgerung 1: Jeder normale Mensch oder doch zumindest fast jeder, hat gelegentlich Erlebnisse von Perfektion.

Folgerung 2: Ich behaupte, daß die Fähigkeit zur Perfektion bei einem Menschen permanent vorhanden ist, wenn sie sich nur einmal gezeigt hat. Als Datenverarbeiter fällt uns dieser Schluß nicht schwer: Die "Hardware" zur Perfektion muß in uns angelegt sein. Daß (maschinelle) Hardware nicht immer das leistet, was potentiell möglich wäre, kennen wir aus unserer betrieblichen Praxis. Eine Erklärung für die übliche Minderleistung, aus dem Erfahrungsbereich der Informatik, kennt jeder: konkurrierende, sich gegenseitig behindernde und blockierende Prozesse.

Kommen wir zurück zur Software-Entwicklung, so heißt das bisher Behauptete nicht mehr und nicht weniger, als daß in uns ein gewaltiges Potential ruht, perfekte Software zu erstellen. Wir brauchten uns im Prinzip nur dieses Potential zu erschließen, und das Problem Softwarequalität hätte in dieser Form aufgehört zu existieren.

Beispiel 2: "Superprogrammer-Trainings"

Peps war mehrere Jahre, von 1975 bis 1978, ein freiberuflicher Mitarbeiter in unserem Softwarehaus, der "Gesellschaft für Systementwicklung" in München gewesen, und wir hatten, da uns das Thema interessierte, über seine Fähigkeiten Buch geführt. Wenn Peps so richtig in einer Produktionsphase war, dann schrieb er über Monate hinweg ziemlich gleichbleibend zirka 1500 Statements Assembler am Tag. (Wir hatten damals sehr anspruchsvolle Projekte aus der Systemprogrammierung, die fast immer in Assembler geschrieben werden mußten.)

Dieses Coding enthielt ziemlich regelmäßig fünf bis sechs logische Fehler. Peps liebte es, in den Abend- und Nachtstunden zu programmieren, und einen Teil des nächsten Tages verbrachte er dann damit, die Fehler zu beseitigen. Im November 1982 - ich war in der Zwischenzeit zur Universität gegangen, und Peps arbeitete für Siemens - rief er mich aufgeregt an: "Meine Fehlerrate, du weißt doch, ist auf Null gefallen. Ich habe in den letzten drei Tagen keinen einzigen Fehler entdeckt. Ich fühle mich supraleitend. So etwas ist mir in meinem ganzen Leben noch nicht passiert."

Was war geschehen? Peps hatte an den beiden vorausgehenden Wochenenden an einem Psycho-Training teilgenommen, das Amerikaner in München anboten. Als Ergebnis fühlte er sich als ein völlig anderer Mensch. Er hatte zum Beispiel - Peps war ein starker Raucher - spontan mit dem Rauchen aufgehört. Begeistert berichtete er mir von seinen Erlebnissen. Das Rauchen hat Peps nach einigen Monaten wieder angefangen, aber die Fehlerrate blieb - fast - auf Null. Über die Details befragt, sagte er später: "Ich verhaue mich immer noch hin und wieder, drücke die falsche Taste oder ähnliches. Aber meine logischen Fehler haben aufgehört. Sobald ich ein Problem perfekt verstehe, codiere ich es auch perfekt."

Ich habe mich damals sehr für dieses Training interessiert und viele Stunden Interviews mit anderen Teilnehmern aus der Softwarebranche geführt. Peps stand keineswegs allein mit sensationellen Veränderungen. Allerdings bezogen sich die meisten Teilnehmer nicht auf den Punkt Fehlerrate, sondern auf Einsatzwillen und die Fähigkeit, ein Problem zu lösen.

Dieses Beispiel erhärtet die These, daß unsere geistigen Produkte Spiegelbilder unseres inneren Zustandes sind. In dem Maße, in dem es gelingt, unsere inneren Widersprüche aufzulösen - und das ist ein Ziel dieses Psychotrainings - bauen wir auch weniger Widersprüchlichkeiten, etwa Programmierfehler, in unsere Umwelt ein, in unsere Beziehungen zu den Mitmenschen, unseren täglichen Lebensablauf und in unsere kreativen Produkte, zum Beispiel in Form von Software. Unsere inneren parallelen Prozesse verhaken sich weniger. Das Leben wird reibungsfreier, leichter, angenehmer, lebenswerter. Man kann auch sagen: Unsere inneren unterbewußten Instanzen sind mehr in Harmonie, in Synergie miteinander. Sie bilden weniger die berühmte Affenherde, die durcheinander springt.

Die Idee mit dem Psycho-Training - wir haben in der Zwischenzeit selbst mehrere Formen von Superprogrammer-Trainings durchgeführt - war übrigens im Endeffekt nicht so erfolgreich, wie sie auf den ersten Blick aussah. Die meisten Menschen neigen nach einiger Zeit dazu, in ihre alten Verhaltensmuster zurückzufallen. Der von mir beschriebene Ansatz über synergetische Teams erscheint mir heute sehr viel natürlicher und effizienter.

Beispiel 3: "Ich will geliebt sein!"

Peps war zwar schon immer, so lange ich ihn kannte, ein hervorragender Software-Mann gewesen, aber er hatte eine entscheidende Schwäche: Er wurde nie mit seiner Arbeit rechtzeitig fertig. Zweimal hatte er versucht, mit einem Partner ein Softwarehaus aufzubauen, und beide Male scheiterte er mit hohen finanziellen Verlusten daran, weil er niemals einen Termin einhielt.

Auch bei uns, der Firma GfS, wo er sich als Freiberufler außerordentliche Verdienste erworben hatte und sehr beliebt war, setzte man ihm 1977, nach meinem Weggang zur Universität, den Stuhl vor die Türe, weil der Geschäftsführer und die Projektleiter zu viele Turbulenzen mit den Kunden auszubaden hatten - für die Peps natürlich nie etwas konnte!

Wie kann jemand gleichzeitig ein Superstar und ein totaler Versager sein, den man hinauswirft. Ich sollte da wohl mit einem Beispiel etwas weiter ausholen:

Um das Jahr 1975 hatten wir den Auftrag, für das Datenbank-System "Prisma" von Siemens einen KDBS-Konverter zu schreiben. Die einzelnen Hersteller von DV-Anlagen hatten damals sehr spezifische Datenbanksysteme auf dem Markt. Das hatte eine starke Abhängigkeit der Kunden zum Hersteller zur Folge, denn einmal eingeführte Hardware konnte praktisch nicht mehr abgelöst werden, sobald die Software auf ein DB-System hin ausgelegt war. Öffentliche Dienststellen in Bayern wollten dem durch Schaffung einer kompatiblen Datenbank Schnittstelle (KDBS) entgegenwirken .

Für die DB-Systeme der einzelnen Hersteller mußten deshalb jeweils Umsetzer geschrieben werden, um die Schnittstellen-Anforderungen zu erfüllen. Da auch die Bereiche des Parallelzugriffs, der Recovery-Prozeduren und der Datenfernverarbeitung betroffen waren, ergaben sich extrem komplexe Umsetz-Programme, die damals nur in Assembler überhaupt denkbar waren.

Wir hatten damals mit Hilfe von Peps eine Ausschreibung bei Siemens gewonnen und gaben die Arbeit vereinbarungsgemäß als Unterauftrag an ihn weiter. Peps werkelte einige Monate vor sich hin, schrieb zirka 50 000 Statements und verkündete etwa drei Wochen vor dem Abgabetermin freudestrahlend, daß an seinem Simulator alles perfekt liefe. Sein Simulator - das war ein hochleistungsfähiges Testsystem von damals vielleicht 100 000 Statements, das er im Laufe der Jahre als sein persönliches Tool entwickelt hatte. (Wir haben später versucht, es unter dem Namen TL/1, Test Language 1, auf den Markt zu bringen.) Peps war mittels dieses Systems in der Lage, das Siemens-Betriebssystem BS1000, das ursprüngliche Prisma-Datenbanksystem und den TP-Monitor an ihren Schnittstellen nachzubilden und den gesamten Ablauf perfekt online zu überwachen.

Das einzige, was jetzt noch geschehen mußte, war das Einbinden und Testen seines Systems mit den Original-Komponenten von Siemens, voraussichtlich keine große Sache. Wir legten bereits optimistisch den Übergabetermin mit Siemens fest. Beim ersten Test in der Original-Software-Umgebung blieb die Maschine stehen, ohne auch nur einen Dump zu erzeugen. Mir als Projektleiter schwante - aus der Erfahrung heraus - mal wieder Fürchterliches.

Nach ein paar Tagen Tag- und Nachteinsatz wurde auch Peps nervös. Er war überzeugt, daß die Fehler - es mußte sich um mehrere sich überlagernde handeln - nicht auf unserer Seite der Schnittstelle zu finden seien.

Professionell begann er damit, sein bereits erwähntes Testsystem zur Überwachung der gesamten Software-Umgebung einzusetzen. Peps fand die Fehler, wie angekündigt, auf der anderen Seite.

Stolz konnte ich unseren Vertragspartnern bei Siemens nachweisen, daß sie schuld an der nun unvermeidlich gewordenen Terminverzögerung seien, und Schadensersatzansprüche für unsere Mehrarbeit anmelden.

Voller Sieg! Aber ... der Umsetzer lief immer noch nicht. Peps förderte neue Fehler zutage, teils in Prisma, meist aber im Betriebssystem. Peps war in der Lage, die Fehler hervorragend zu dokumentieren, und bald war wohl das gesamte BS1000-Wartungsteam bei Siemens damit beschäftigt, die von Peps gefundenen Fehler zu beseitigen.

Man sollte jetzt naiverweise denken, daß die Leute bei Siemens über den gründlichen Test ihrer Software froh hätten sein können und dem kleinen Softwarehaus, das wir waren, seine Mühe finanziell vergelten würden. Aber das Leben spielte mal wieder anders. Unsere Vertragspartner - und das waren bei Siemens nicht die Betriebssystemleute, sondern die Datenbankentwickler, die an einer ganz anderen Stelle der Organisation angesiedelt waren - wurden zunehmend sauer. Sie wollten endlich ihr Produkt auf den Markt bringen und nicht endlose Fehler-Reports an andere Abteilungen weiterreichen.

Wie recht sie damit haben sollten, sah ich damals noch nicht ein. Ich sah nur, daß wir als kleiner, aber hochleistungsfähiger Laden einem Koloß gegenüberstanden, der offensichtlich nicht einmal in der Lage war, uns saubere Schnittstellen zu seinen Standardprodukten zu gewährleisten. Ich hatte das Gefühl, daß wir von Siemens als schwächerer Partner über den Tisch gezogen wurden und reagierte ebenfalls emotional. Schließlich kam es so weit, daß die Siemens-Leute begannen, uns ihrerseits Regreßforderungen anzudrohen. Keine schönen Aussichten angesichts der Tatsache, daß wir einem Rechtsstreit finanziell nicht gewachsen gewesen wären. Da wir stets eine Menge Aufträge von Siemens hatten und sich der Ärger schnell herumspricht, war das alles in allem eine teuflische Situation für unsere Firma. Am unerfreulichsten war sie für Peps, der über Monate hinweg kaum seine Frau zu Gesicht bekam und insgesamt ein sehr mäßiges finanzielles Ergebnis erzielte. Dreieinhalb Monate nach dem Termin konnte der Umsetzer endlich übergeben werden. Soweit das Beispiel, um die Paradoxie Spitzenmann/Versager anzureißen. Der Gag kommt aber erst noch.

Es muß ungefähr 1980 gewesen sein, als wir Shaun de Warren, einen Freund aus London, baten, in unserem Privathaus ein Wochenendseminar zu veranstalten, eine Art Selbsterfahrungsgruppe. Meine Frau und ich hatten bereits an zwei derartigen Seminaren mit Shaun teilgenommen und waren von ihm so begeistert, daß wir unsere Freunde auch dazu einladen wollten. Auch Peps sagte zu. Am Sonntagnachmittag - wir hatten uns gerade in Kleingruppen auf Räume in mehreren Stockwerken verteilt - hörten wir einen Schrei im Treppenhaus, dann lautes Lachen, dann Weinen, dann Lachen. Wir liefen neugierig zusammen, um zu sehen, was da los wäre. Es war Peps. Als er sich beruhigt hatte, berichtete er, er habe plötzlich erkannt, warum er keinen Termin hätte einhalten können. Jeder liebe ihn wegen seiner guten Programme Er wolle aber um seiner selbst willen geliebt werden. Deshalb habe er, ohne daß er sich dessen bewußt gewesen sei, immer wieder alle seine Erfolge zerstört.

Das war der entscheidende Durchbruch. Seitdem hat Peps jeden Termin eingehalten. Die üblichen Turbulenzen in der letzten Projektphase blieben aus. Peps wurde sehr viel erfolgreicher, insbesondere finanziell. Ich kannte den Abteilungsleiter bei Siemens gut, für den Peps als Freiberufler arbeitete und der mit ihm ebenfalls viel Ärger gehabt hatte. Er bestätigte mir später voll und ganz, daß Peps seine Termine ab dem besagten Zeitpunkt eingehalten hätte. Es sei jetzt eine Freude, mit ihm zusammenzuarbeiten.

Das Beispiel hat mir in überzeugender Weise klargemacht, daß es in uns Instanzen gibt, die völlig andere Wertsysteme wie unser bewußtes ICH besitzen. Der Erfolg eines ganzen Berufslebens ist weniger wichtig als ein bißchen Aufmerksamkeit. Derartige Fälle sind jedem Psychotherapeuten bestens vertraut: die Frau zum Beispiel, die Angst hat, durch Attraktivität ihre Ehe zu gefährden und so viel ißt, daß sie unansehnlich wird.

Das Verhalten erscheint auf den ersten Blick irrational, ist es jedoch, aus der Sicht der Realität dieser Instanzen, keineswegs. Wenn es aber rational ist, dann gibt es im Prinzip auch Möglichkeiten, die dahinterstehende Logik zu begreifen und möglicherweise, wie bei Peps, dramatische Änderungen auszulösen.

Mit Superintelligenz Fehler einbauen

Den letzten Teil der Geschichte habe ich noch nicht berichtet. Ich hatte 1984 bis 1986 einen Forschungsauftrag zum Thema Superprogramming, in dessen Verlauf ich zahlreiche Interviews mit hochkarätigen Softwareleuten durchführte. Ich stellte fest, daß die meisten Software-Entwickler - wie auch andere Leute - sich nicht bewußt sind, auf welche Weise sie denken. Beispielsweise finden sie einen Fehler in ihrem Programm, wenn sie nachts wach liegen. Sie stellen sich dabei ihr Programm intensiv vor. Viele sind jedoch nicht auf Anhieb in der Lage, zu sagen, was sie sich da vorstellen, das heißt, welche Bilder sie vor ihrem geistigen Auge entstehen lassen. Das sind in den seltensten Fällen die Programmtexte, die sie eingetippt haben, sondern zum Beispiel dreidimensionale farbige Architekturen.

Wir entwickelten also in diesem Projekt auf der Basis von NLP psychologische Techniken, die es Softwareleuten ermöglichen, sich ihre Bilder bewußt zu machen, weil wir auf ihrer Basis eine grafische Programmiersprache entwickeln wollten. Dazu gehört viel Zeit und Geduld, damit sich die Leute entspannen können und die Muße haben, sich wirklich ihre eigenen Denkstrukturen anzuschauen. Nach gewöhnlich ein bis fünf Stunden kommt eine Menge an Einsichten heraus, die die Betreffenden selbst überraschen.

Auch mit Peps führte ich einige lange Analyse-Interviews, und irgendwann kamen wir auf das alte KDBS-Projekt zu sprechen. Peps konnte mir jetzt bis ins letzte Detail erklären, wie er es angestellt hatte, den Erfolg seiner Software zu boykottieren. Er erzählte mir, wie er Systemfehler und irreguläres Verhalten der Siemens-Produkte geschickt miteinander kombiniert und in einer Weise ausgenutzt hatte, daß das Programm auf der anderen Seite abgestürzt sei. Die "Kunst" bestand darin, das Ganze so zu inszenieren, daß es seiner gesamten Umwelt und ihm selbst verborgen blieb. Es hätte nicht gereicht, nur irgendwelche Systemfehler bei Siemens auszunutzen, sondern deren Auswirkungen mußten sich auch noch in einer Weise überlagern, daß es irgendwo innendrin krachte. Selbstverständlich war nie ein Fehler auf unserer Seite beteiligt. Peps erkannte auch nachträglich, daß er damals einen unwiderstehlichen Zwang gespürt habe, recht zu behalten und "es denen zu zeigen". Wörtlich sagte er:

"In der Siemens-Software waren, wie in anderer Software auch, eine Menge Fehler, und die sind auch jetzt noch drin. Ich arbeite immer noch mit den gleichen Produkten, aber die Fehler interessieren mich heute nicht, die umgehe ich. Das macht jeder, denn sonst kann man nicht leben."

Und dann: "Die Intelligenz, die ich damals, ohne es zu wissen, aufgebracht habe, um die Siemens-Software so geschickt auf den Bauch fallen zu lassen, war um ein Vielfaches höher als die Intelligenz, die nötig war, den Konverter zu bauen."

Den letzten Satz kann ich nach den Details, die er mir schilderte, nur voll bestätigen, und er ist für mich von besonderer Bedeutung. Ich hatte Peps stets bewundert für seine fantastischen und eleganten Lösungen in äußerst komplexen Situationen: ein absolutes Genie. Und jetzt zeigte er mir anhand konkreter Beispiele, daß seine Intelligenz noch um ein Vielfaches höher gewesen sein mußte, wobei er diese extremen Fähigkeiten in destruktiver Weise genutzt hatte. Unsere Vertragspartner bei Siemens hatten so etwas wohl irgendwo geahnt.

Peps ist kein Einzelfall

Die Frage liegt nahe: Warum sollte Peps eigentlich ein Einzelfall sein. Wäre es nicht denkbar, daß wir alle - ohne es zu wissen - weit mehr Intelligenz in das Verstecken unserer Fehler investieren als ins Programmieren? Peps wollte mit seinen "Fehlern" etwas erreichen: mehr geliebt zu werden. Das ist ihm im klassischen Sinne sicher nicht gelungen, aber er hat sehr viel Aufmerksamkeit bekommen.

In NLP geht man davon aus, daß es für jedes Verhalten eines Menschen einen Gewinn, einen "secondary gain", gibt. Je intelligenter sich also seine Umwelt verhält, desto mehr muß ein Programmierer, der seine Fehler mit Absicht macht, sich anstrengen, seinen Gewinn dennoch zu realisieren.

Anders herum ausgedrückt: Je mehr klassische Methoden wir einsetzen, um Fehler schwieriger zu machen oder aufzufinden, desto mehr fordern wir die Leute heraus, ihre Fehler noch geschickter zu verstecken. Das ist wie bei der Spionage-Abwehr, ein endloses Karussell.