Eule
S a a r b r ü c k e r   B i b l i o t h e k

(http://www.jura.uni-sb.de/projekte/Bibliothek)

Erstveröffentlichung:
Festgabe für Günter Krohn,
Informationstechnologien und
Juristische Praxis , S. 45 - 56




Maximilian Herberger



Zehn Gebote für den klugen Umgang (vielleicht nicht nur) des Juristen mit der EDV*





"Jedes Zeichen war eine Zahl. Für eins machst du ein Zeichen, für zwei ein anderes, für drei wieder ein anderes, und so weiter." "Wozu?" "So konnten die Leute ohne Computer rechnen. Natürlich mußten sie wissen, was die verschiedenen Zeichen bedeuteten. Mr. Daugherty sagt, daß früher alle Kinder diese Zeichen lernen mußten. Sie wurden auf Papier gemalt, das nannte man 'schreiben'. Und das Entschlüsseln nannte man 'lesen'. Er sagt, früher hätten die Leute ganze Bücher in solchen Zeichen geschrieben, und es gäbe noch welche im Museum, und wenn ich wollte, könnte ich sie mir ansehen. Ich habe schon alle Zahlen bis neun gelernt."

(Isaac Asimov, Der Märchenerzähler, in: Schlaue Kisten machen Geschichten, hrsg. v. Ruth J. Kilchenmann, o.O. 1977, S. 217 -226, 223.)



Vorbemerkung

Die Juristen erheben mit der Bezeichnung "Jurisprudenz" den Anspruch, über eine praxisorientierte Klugheitslehre für den Umgang mit dem Recht zu verfügen. Soll der EDV-Einsatz der Juristen mit diesem Anspruch Schritt halten, sind Anstrengungen unumgänglich, auch für diesen Teil der juristischen Tätigkeit Klugheitsstandards zu entwickeln, die dem entsprechen, was die Juristen für den Umgang mit dem Recht postulieren. Der Akzent liegt dabei ebenso auf "Klugheitslehre" wie auf "praxisorientiert". Für das ausschließlich theoriegeleitete Bemühen auf dem Gebiet der Rechtsinformatik mag manches (wenn auch nicht alles) anders aussehen als hier empfohlen.


 1. "If it ain't broken, don't fix it"
 2. Übe Dich in der Software-Askese,
     oder: Nicht jede neue Version verdient Aufmerksamkeit
 3. Wappne Dich gegen den zufälligen Wandel (so gut es geht),
     oder: Richte den Blick, auf das, was bleibt
 4. Beachte den Primat des zu Erledigenden,
     oder: Das Mittel ist nur Mittel zum Zweck
 5. Wähle das richtige (im Sinne von: zweckadäquate) Mittel
 6. "Small is beautiful",
     oder: Vom eigenen Charme des Unaufwendigen
 7. Tue nicht alles selbst
 8. Versuche zu verstehen, was das Programm tut
 9. Bewahre die Fähigkeit,
     das tun zu können, was das Programm tut
10. Bleibe Herr der Dinge


1. "If it ain't broken, don't fix it"

Der unter amerikanischen Programmierern beliebte Satz, daß man etwas Nicht-Defektes nicht reparieren soll, gehört an den Anfang jeder EDV-Klugheitslehre. Immer wieder wird man erleben, daß angesichts einer nicht mit erkennbaren größeren Fehlern behafteten EDV-Lösung ein Spezialist (manchmal ein selbsternannter) auf den Plan treten wird, der mit großer Überzeugungskraft behauptet, man könne all dies wesentlich eleganter bewerkstelligen. So sehr das Streben nach höherer Eleganz ein Antriebsmoment für den Theorienfortschritt sein mag, so sehr sollte man sich in der Praxis im Regelfall diesem Ansinnen entgegenstellen. Denn häufig endet die Verschönerung eines angeblich allzu hausbackenen (aber immerhin nicht ersichtlich fehlerhaften) Programms bei einem wirklich fehlerhaften Programm (mindestens für einen nennenswerten Zeitraum). Rechnet man dann die Vorteile des Erreichten gegen den Aufwand bis dorthin, wird man sich schmerzlich daran erinnern, daß "If it ain't broken, don't fix it" wirklich eine Klugheitsmaxime ist.

2. Übe Dich in der Software-Askese,
oder: Nicht jede neue Version verdient Aufmerksamkeit

Die Entwicklungszyklen im Software-Bereich werden immer kürzer.
Eine neue Version jagt förmlich die andere. Wer über eine nennenswerte Anzahl von Programmen verfügt, kommt mit dem "Updaten" (so sagt man) nicht nach. Die Klugheit fragt danach, ob man sich dieser scheinbaren Zwangsläufigkeit aussetzen muß, und antwortet verneinend. Der (zugegebenermaßen einfache) Grund liegt darin, daß das Neue nicht per se als das Bessere oder Geeignetere angesehen werden kann, weswegen man ein Prüf-und Auswahlprinzip benötigt. Dieses könnte lauten: Wenn die Version des Programms, das Du einsetzt, alles von ihm Erwartete und für die Arbeit Nötige in ausreichend benutzerfreundlicher Weise leistet, besteht kein Anlaß, sich durch eine neue Version beunruhigen zu lassen. Umgekehrt: Nur wenn das verwendete Programm Mängel hat oder bezogen auf notwendige Arbeitsziele Defizite aufweist, besteht Anlaß, eine neue Programmversion daraufhin zu prüfen, ob sie diesbezüglich besser abschneidet.

(Um möglichen Mißverständnissen vorzubeugen: Es versteht sich von selbst, daß unnötige Umständlichkeiten im Bereich der Handhabung zu den Restriktionen gehören, deren Überwindung angezeigt ist, so daß hier der Software-Fortschritt zu prüfen bleibt. Aber auch da gilt: Das Neue ist nicht per se software-ergonomisch gelungener als das Alte.)

Software-Askese1 steht im übrigen mit der alten Tugend der Sparsamkeit in einem engen inneren Zusammenhang, was beweist, daß alte Moralphilosophie auch kategorial Neuem (wie der Software) gewachsen sein kann: Man kann sparsam mit den Ressourcen umgehen, weil nicht jede Aufforderung zu erhöhtem Verbrauch (um nicht zu sagen: zur Verschwendung) auf zweckbedingter Notwendigkeit beruht.

3. Wappne Dich gegen den zufälligen Wandel (so gut es geht),
oder: Richte den Blick, auf das, was bleibt

Spektakuläre Firmenübernahmen und überraschende Produktionseinstellungen machen immer wieder darauf aufmerksam, von welchen Zufälligkeiten der EDV-Anwender abhängt und unter welcher Bedrohung das für ein bestimmtes kommerzielles Programm eingesetzte Zeitbudget steht. Hat ein Programm den Konsolidierungsgrad erreicht, von dem eben die Rede war, so mag man sich damit beruhigen, daß weitere Entwicklungen ohnehin für die eigene Arbeit nichts entscheidend Besseres hätten erbringen können. Hat man sich aber aus wohlerwogenen Gründen, was auch oft vorkommt, für ein noch nicht ganz ausgereiftes Produkt entschieden, und dies im Vertrauen auf die Weiterentwicklung, so wird man von der Produkteinstellung oder dem Übergang des Produkts an eine Firma, die es kaum noch pflegt, schmerzlich betroffen.

Die Diagnose ist klar, die Therapie nicht einfach: Gibt es klugheitsorientiert überhaupt eine Möglichkeit, sich gegen derartige Wechselfälle des Lebens und der Wirtschaft zu wappnen? Es gibt sie, wenn auch nicht im Sinne eines Patentrezepts, sondern nur als heuristische Regel, die die Wahrscheinlichkeit, unangenehm überrascht zu werden, in nennenswerter Weise verringert.

Der Schlüssel zum Erfolg liegt darin, daß man sein Gespür für dauerhafte Strukturen schärft. Einer Firma zu vertrauen, mag sie noch so groß und noch so alt sein, ist risikoreicher, als sich auf übergreifende Kooperationszusammenhänge zu verlassen. Derartige Kooperationen mit einem allemal haltbareren verzweigteren Wurzelwerk trifft man beispielsweise im Bereich der "Public Domain"-Software an. Der Hinweis auf Donald Knuth's TEX mag genügen um zu veranschaulichen, was gemeint ist (vgl. für eine Kurzcharakteristik meinen Beitrag "Software für juristische PC-Räume" in: Eberle, Informationstechnik in der Juristenausbildung, München 1989, S. 83 -113, 92f.). Die weltweite "TEX-community" ist - wie die bisherige, gar nicht so kurze Geschichte zeigt - gegen Wechsel im Hard- und Software-Bereich recht resistent und produziert rund um TEX immer wieder angemessene und innovative Lösungen - meist übrigens dem Geist der "Public Domain" entsprechend altruistisch. Man ist vor diesem Hintergrund versucht, die Hilfsregel zu erwägen, daß das Uneigennützige mehr Aussicht auf Bestand hat als das Eigennützige.

4. Beachte den Primat des zu Erledigenden,
oder: Das Mittel ist nur Mittel zum Zweck

Wer kennt nicht die folgende Situation: Anläßlich der Erledigung einer Aufgabe mit Mitteln der EDV verhält sich das Gerät oder das Programm an einer Stelle nicht so, wie es sollte. Man kann diesen unerwarteten Zustand leicht umgehen und das Ziel auf diesem naheliegenden Umweg nur mäßig umständlicher erreichen. Trotz dieses naheliegenden "workaround" (ein in EDV-Kreisen bis hin zu AGB's nicht ohne Grund zunehmend beliebter werdender Ausdruck) liefert man sich ein gnadenloses Duell mit dem Rechner, bis er das Gewollte genau so wie gewollt tut. Ein wenig trägt dieser erbitterte Kampf Züge von "Er oder ich", als müsse man als Herr und Meister dem Instrument sogar in den Einzelheiten der Ausführung den eigenen Willen aufzwingen. Hin und wieder mag das zu Lernzwecken nützlich sein. Auf's Ganze gesehen ist es unvernünftig, weil das eigentlich zu Erledigende, dem schließlich der Primat zukommt, dabei aus dem Blick gerät.

5. Wähle das richtige (im Sinne von: zweckadäquate) Mittel

Die Faszination der EDV-Technologie verführt oft dazu, sich bei der Erreichung eines Ziels interessante technische Möglichkeiten zunutze zu machen, die den Scharfsinn herausfordern, aber im Vergleich mit anderen Mitteln ganz unzweckmäßig sind.

Ein (durchaus nicht fiktives) Beispiel mag diese Behauptung veranschaulichen: Ein Schriftsatz für einen Korrespondenzanwalt ist mittels Textverarbeitung erstellt worden. Mit Hilfe eines anspruchsvollen Fax-Programms wird dieser Schriftsatz nun direkt aus der Textverarbeitung an den Kollegen gefaxt. Dieser setzt OCR-Software ein, um das zugefaxte Bild (Fax übermittelt Bilddateien) wieder in den Text zurückzuverwandeln, der es einmal war, um dann mit der Textverarbeitung eine Überarbeitung vorzunehmen. Angesichts der Tatsache, daß man Texte von Rechner zu Rechner (übrigens sogar über das normale Telefonnetz) direkt als Text übertragen kann, ist das eine ganz unangemessene Verfahrensweise. Wer aber die Personen aus dem Beispiel einmal begeistert über den von ihnen betriebenen Aufwand hat sprechen hören, wird das Postulat der Auswahl des zweckadäquaten Mittels bei aller Selbstverständlichkeit der Einschärfung für Wert halten.

6. "Small is beautiful",
oder: Vom eigenen Charme des Unaufwendigen

Wenn eben für die Wahl des zweckadäquaten Mittels votiert wurde, so ist darin implizit auch die These enthalten, daß nicht mehr Aufwand getrieben werden darf, als es der Zweck erfordert. Trotzdem verdient dieses Corollarium im Sinne der Verdeutlichung eine zusätzliche Betrachtung.

Wieder soll ein Beispiel in die Problemlage einstimmen. Setzen wir den Fall, daß ein Jurist einen Text erstellen will, der außer einfachen Auszeichnungen wie Fett oder Kursiv keine weiteren Gestaltungsmerkmale enthält. Es ist heutzutage nicht mehr selten, daß er zu diesem Zweck einen Rechner mit 8 MB Hauptspeicher und graphischer Benutzeroberfläche anwirft und dann ein hochkarätiges Textverarbeitungsprogramm aufruft, das überdimensional viel mehr erlaubt, als vorliegend gefordert ist.

Ist es schädlich, so zu verfahren? Man sollte sich das hin und wieder bewußt fragen, da es nicht nur um die ästhetische Qualität der unaufwendigen einfachen Lösung geht, sondern zusätzlich um die Frage der Ressourcen-Verschwendung. Und wie so oft, erweist sich das Sparsame auch unter anderen Aspekten als das Nützliche: Nicht selten ist die "kleinere" Lösung auch unter sekundären Aspekten wie Geschwindigkeit, Stabilität, Bedienungsleichtigkeit etc. die bessere.

7. Tue nicht alles selbst

Arbeitsteilung ist nicht ohne Grund entstanden und hat als Spezialisierung meist ihren Nutzen. Immer leistungsfähigere Programme entfalten eine gegenläufige Tendenz und verführen dazu, alles selbst machen zu wollen. In einer Karikatur, die ich kürzlich sah, meint ein Manager in diesem Sinne: "Mein neues Programm erlaubt es mir, Texte so zu schreiben, wie dies früher meine Sekretärin getan hat, sie so zu gestalten, wie dies früher unsere Hausdruckerei getan hat, zu buchen, wie dies früher mein Buchhalter tat ... (usw.)". Jeder mag in dieses Schema selbst die Beschreibung dessen einsetzen, was er früher nicht selbst getan hat, nun aber mit Mitteln der EDV meint selbst tun zu müssen (und zu können). Sicher ist es gut, dazuzulernen und sich neue Tätigkeitsfelder zu erschließen. Nur muß man sich dabei darüber im Klaren sein, daß das Programm, das anscheinend (und manchmal sogar nur scheinbar) all dieses Neue erlaubt, nicht auch noch durch eine Art Osmose die für ein Anwendungsumfeld nötige Kunstfertigkeit und das dort geforderte handwerkliche Können mit vermittelt. Die Wahrheit dieser These ist etwa beim Desktop-Publishing allerorten zu beobachten: Die vielfältigen Möglichkeiten, das Aussehen eines Textes zu gestalten, werden oft exzessiv genutzt, ohne daß dieser Gestaltungsdrang durch das Wissen moderiert würde, das sich ein guter Setzer in langer Ausbildung und Übung erworben hat. Deshalb wäre es oft besser, ohne entsprechende Ausbildung die Textgestaltung den dafür Kundigen zu überlassen.

Wie viele Klugheitsregeln, so ist auch die eben behandelte in Gestalt des Sprichworts "Schuster, bleib bei Deinem Leisten" dem Volksmund wohl vertraut (was nicht gegen sie spricht).

8. Versuche zu verstehen, was das Programm tut

Je "mächtiger" (so sagt man heute gerne in EDV-Kreisen) Software wird, desto mehr ist die Fähigkeit des Anwenders gefährdet, zu verstehen, was das Programm im Einzelfall wie tut. Das Phänomen hat seine Vorläufer in einfacheren Zusammenhängen: Spätestens seit es Taschenrechner gibt, dürfte die Fähigkeit, bestimmte Berechnungen im Kopf oder auf Papier durchführen zu können, zu einer gefährdeten Kulturtechnik geworden sein. Und wem kann man beispielsweise heute noch zutrauen, daß er in der Lage wäre, eine Quadratwurzel ohne andere Hilfsmittel als Papier und Bleistift auszurechnen?

Doch das sind, wie gesagt, nur die Vorläufer des Problems, das heutzutage auf uns zukommt. Es gibt Juristen, die berechnen als notwendige Vorfrage für die juristische Behandlung des möglicherweise sittenwidrigen Kredits mit EDV-Instrumenten Zinssätze von Ratenkrediten, ohne zu wissen, was sich dabei im einzelnen abspielt. So ist man dem Instrument hilflos ausgeliefert - und das erweist die Redeweise von der "mächtigen" Software in einer hintergründigen zweiten Lesart in dem Sinne als zutreffend, daß wir uns den Zwangsläufigkeiten der Instrumentarien ausliefern, uns von ihrer "Macht" überwältigen lassen. Was aber, wenn die Programme Fehler machen und wir mangels Verständnisses gar nicht mehr ahnen, daß dem so sein könnte? Nebenbei bemerkt: Gerade bei dem Beispiel der Programme zur Berechnung von Ratenkrediten ist die Frage nicht nur rhetorischer Art. 

9. Bewahre die Fähigkeit,
das tun zu können, was das Programm tut

Von der Kompetenz, im Prinzip angeben zu können, was ein Programm wie bewerkstelligt, ist die (weitergehende) Fähigkeit zu unterscheiden, auch selbst das tun zu können, was das Programm tut. Insofern ist dieses Postulat eine Verschärfung des vorhergehenden. Eine Geschichte (es ist eine Science-Fiction-Erzählung, deren Fundstelle ich nicht mehr verifizieren kann) mag veranschaulichen, worum es geht: In ferner Zukunft ist auf einem entlegenen Planeten ein riesiges Raumschiff mit Tausenden von Besatzungsmitgliedern zur Notlandung gezwungen gewesen, weil die EDV-Anlage für die Kursberechnung ausgefallen war. Es bricht große Verzweiflung aus, man sieht sich rettungslos verloren. Doch dann entwickelt jemand den Plan, durch geschickte Verteilung von Rechenaufgaben die Berechnung des Rückflugkurses so zu organisieren, daß alle an Bord wie Rechenwerke eines Großrechners kooperieren. So gelingt das bewußtseinsmäßig schon nicht mehr als reale Möglichkeit Präsente: Die Erledigung einer Aufgabe durch Menschen, die nur noch "dem Rechner" zugetraut wurde.

Die Möglichkeit des Erfolges "in fabula" beruht zum einen darauf, daß das vorhergehende Postulat realisiert war. Das Know-How für Kursberechnungen war an Bord des Raumschiffs vorhanden. Hinzukommen muß aber bei komplexeren Aufgaben eine Menge von handwerklichem und arbeitsorganisatorischem Wissen. Das prinzipielle "Gewußt wie" ist notwendige, nicht jedoch auch hinreichende Bedingung für das "Gewußt was". Eine milde Sicht der Dinge könnte geneigt sein, der darin liegenden Ausweitung des Pflichtenkatalogs auszuweichen und es bei der Forderung nach begleitendem prinzipiellen Verstehen bewenden zu lassen. Doch liefe auch das auf eine Abdankung als Herr des Geschehens hinaus, hieße es doch, daß die Wegnahme der EDV-Hilfsmittel die Unmöglichkeit eigenständiger Problemlösung nach sich zieht. An dieser Stelle ist ein Punkt erreicht, wo man sich fragen muß, ob wir nicht in größeren Organisationszusammenhängen sozial schon den Zustand erreicht haben, dem das eben besprochene Postulat entgegenwirken soll: Gibt es nicht bereits Bereiche, wo die Dinge so organisiert sind, daß bei Ausfall der EDV die geschuldete Arbeit gar nicht mehr erbracht werden könnte (und nicht nur langsamer oder mühevoller)? So wichtig es ist, dieser Frage nachzugehen, so wenig darf man sich durch diese globale Fragestellung davon ablenken lassen, daß man es am eigenen PC-Arbeitsplatz, im Bereich der eigenen "Organisationshoheit" nicht dahin kommen lassen sollte, weniger kompetent zu sein als der Rechner. Oder, wie Dreyfus und Dreyfus es ausdrücken:

"The chips are down, the choice is being made right now. And at all levels of society computer-type rationality is winning out. Experts are an endangered species. If we fail to put logic machines in their proper place, as aids to human beings with expert intuition, then we shall end up servants supplying data to our competent machines. Should calculative rationality triumph, no one will notice that something is missing, but now, while we still know what expert judgement is, let us use that expert judgement to preserve it" (Hubert L. Dreyfus/Stuart E. Dreyfus, Mind over machine: The power of Human Intuition and Expertise in the Era of the Computer, New York: The Free Press 1986, S. 206; vgl. dazu Marion Drücker, Informatik und Recht 1987, S. 165 - 168, 205 - 209).

10. Bleibe Herr der Dinge

Sucht man nach einer Meta-Regel, die das bisher Erörterte zusammenfaßt, so bietet sich das Souveränitätspostulat "Bleibe Herr der Dinge" an. Es bliebe ohne Entfaltung im Einzelnen zu pauschal, hat aber als Merkposten für im Detail Begründetes durchaus seine Bedeutung. Auch dazu eine (diesmal selbsterlebte) Geschichte.

In einem EDV-Geschäft in der Nähe von Münster, das es mittlerweile konkursbedingt schon lange nicht mehr gibt, erscheint ganz in Ledermontur ein Motorradfahrer und erkundigt sich nach einem Gerätetreiber, den es - wie man ihm sagt nicht gibt. Darauf erwidert er gedankenschwer: "Ich könnte den Treiber ja schlimmstenfalls selber schreiben, wenn ich nur wüßte wie."

Ja, wenn wir eines Tages nicht mehr wissen wie - was wäre dann (vgl. das vorangestellte Zitat)?


*Diese Überlegungen wurden bei der Eröffnung des Deutschen EDV-Gerichtstages 1993 in Saarbrücken vorgetragen und sind hier nur geringfügig erweitert worden. Die Vortragsform ist beibehalten.

1 Erfreulicherweise hat gerade dieser Punkt bereits Resonanz in der Praxis gefunden; vgl. Dieter Schmidt, Grußwort zur Marburger Fachtagung "Die zweite Geburt der Rechtsinformatik", jur-pc 1993, S. 2344 - 2346, 2345.


Zum GESAMTKATALOGZum ANFANG des Dokuments