VERFEHLTE INDIVIDUATION 99 blieb dabei für den Anwender völlig im Dunkeln.1 Das Programm hatte die eingehenden Daten gewertet, Entscheidungen getroffen und so verblieb manches, was sich zu einem Musikstück hatte fügen sollen, im immateriellen Nichts oder ordnete sich zu kuriosen Notenfolgen. Spätere Pro-grammversionen hoben diese Eigenwilligkeit weitgehend wieder auf - offensichtli-che Programmierfehler wurden von dem Programmiererteam also aufgehoben. Die Betonung liegt hier auf offensichtliche Fehler, da vielleicht andere, sich nicht so eindringlich offenbarende Fehlprogrammierungen nicht korrigiert, weil gar nicht entdeckt wurden. Gerade solche Programmroutinen, welche - im Sinne des Programmierers - „fehlerhaft“ konzipiert sind und sich nicht gleich in Form von Systemabstürzen für jeden ersichtlich als solche offenbaren, sind erwähnenswert und interessant, da in diesen Fällen sich ein Programm unmerklich für Programmierer und Anwender quasi als komponierende Instanz mit in die Komposition einschreibt. Das als Feh-ler Proklamierte offenbart sich als weiterer, unmerklich bleibender Schritt zur In-dividuation von Computerprogrammen und damit von Computern. Komplexe Da-tenmanipulationen erlauben keine völlige Überprüfbarkeit der gelieferten Ergeb-nisse, allein auch schon deshalb nicht, weil zum einen angebotene Datenmanipula-tionen mitunter gar keine analogen, vergleichbaren Entsprechungen mehr haben, ein Anwender also gar nicht wissen kann, was er für Ergebnisse überhaupt erwar-ten darf und sich somit fast jedes Ergebnis für ihn als ein „richtiges“ ausnimmt, und zum anderen, weil auch der Programmierer gar nicht mehr alle von ihm ge-knüpften Verweisebenen und damit Kombinationsmöglichkeiten kennt. Aufgrund dieser fehlenden Kenntnis wird ja auch ein jedes neues Programm von sogenannten „B“-Testern erprobt, die nicht nur die vorgesehenen Funktionen abru-fen und erproben, also bedienungsgemäß mit dem Programm umgehen, sondern darüber hinaus völlig irrelevante Tastenkombinationen abrufen, um so innerhalb des Programmnetzwerkes nicht geplante Verknüpfungen aufzuspüren. Im Idealfall würden bei einem derartigen Testverfahren alle Kombinationsmöglichkeiten von Programmen - auch und gerade die unwahrscheinlichsten - durchprobiert, um so ein fehlerhaftes Prozessieren auszuschließen, was aufgrund der Komplexität von Programmen aber weiterhin unmöglich bleibt, so daß auch bei den bewährtesten und zuverlässigsten Programmen immer mit scheinbar zufällig auftretenden Aus-fällen zu rechnen ist. Und so bleibt schließlich nur der Weg des täglichen Umgangs mit der Software, um Programme zu qualifizieren. „Gebrauchswert und Zuverläs-sigkeit des Programms werden in der Nutzung ‘validiert’.“2 Es folgt daraus, daß - wo immer man auch mit Software operiert - diese zu ir-gendeinem Zeitpunkt immer auch nicht voraussehbare Effekte zeitigen wird. Das gilt auch uneingeschränkt da, wo Software durch Zuverlässigkeit besticht. Solcher-lei Unwägbarkeiten sind dem Prinzip des Software-Programming immanent: Auf 1 Angesprochen werden hier Erfahrungen, die ich mit jenem Programm gemacht habe. 2 Coy, Wolfgang: Aus der Vorgeschichte des Computers. In: Bolz, Norbert/Kittler, Friedrich/Tholen, Georg Christoph (Hg.): Computer als Medium. München 1994, S. 34