Theoriebildung und Softwaredesign

Themenanfang

Ich bin der Meinung, daß Theoriebildung und Softwaredesign sich an zentraler Stelle berühren: beides beschäftigt sich mit der Abstraktion (d.h. Reduktion) von Komplexität. Wenn man von systemtheoretischen Überlegungen ausgeht, landet man fast zwangsläufig bei der Idee, daß ein Programmierer es auf nahezu identische Weise mit Komplexität zu tun hat, wie ein Physiker oder Soziologe. Luhmann z.B. spricht öfters von Entscheidungen, die man für oder gegen ein bestimmtes Theoriedesign treffen müsse.

Aus konstruktivistischer Sicht gibt es nur plausible, aber keine deterministischen Erklärungen für die Sicht auf „Welt”. Ähnlich sieht das aus, wenn man ein Programm schreibt: es gibt kein „richtiges” Softwaredesign, sondern nur eines, das praktikabler ist als ein anderes. Theorie- wie auch Programmdesign stehen ständig auf dem Prüfstand - sie sind nie „richtig” oder „wahr”, sondern müssen stets den praktischen Erfordernissen angepaßt werden.

Wenn man versucht, eine Beobachtung der Wirklichkeit zu erklären, geht es traditionell darum, Ursache und Wirkung zu trennen. Man beobachtet etwas, und fragt nach dem „Warum”. Diese Art der Erklärung funktioniert aber dann nicht mehr, wenn man Wirklichkeit nicht mehr als etwas objektiv gegebens betrachtet, sondern sie sich nur noch aus ihrer Wahrnehmung erklären läßt. Aus konstruktivistischer Sicht ist das Einzige, was man über Beobachtungen sagen kann, daß ein Beobachter sie beobachtet. Realität wird dadurch nicht obsolet oder verleugnet, erscheint aber gewissermaßen nur noch als Horizont, als unerreichbares Ziel.

Die These des operativen Konstruktivismus führt also nicht zu einem „Weltverlust”, sie bestreitet nicht, daß es Realität gibt. Aber sie setzt Welt nicht als Gegenstand, sondern im Sinne der Phänomenologie als Horizont voraus. Also als unerreichbar.

(Niklas Luhmann. Die Realität der Massenmedien. Wiesbaden 2004, S.18)

Es gibt - aus dieser Sicht - keine Ursachen, die die Außenwelt „steuern” (zumindest wäre es für den Beobachter unmöglich, diese festzustellen), sondern nur noch die Differenz zwischen Beobachter und Außenwelt. Diese Differenz läßt sich - indem der Beobachter seine eigene Rolle rekursiv ins System einspeist - als System beschreiben; in letzter Konsequenz: als Programmdesign.

Automaten erfüllen zwei Intentionen: Ingenieure konstruieren Automaten, um die Arbeit zu rationalisieren, Systemtheoretiker konstruieren Automaten, um Phänomene zu erklären. In Erklärungen heissen die Automaten System.

(Rolf Todesco)

Es gibt also gute Gründe, einmal genauer hinzusehen, wie Softwareentwickler „denken”, wenn sie ein Programm (einen Automaten) entwerfen. Vielleicht läßt sich das ja in einem zweiten Schritt um 180 Grad drehen, um näheres davon zu erfahren, wie man vorgehen könnte, wenn man System-„Erklärungen” aus dem konstruieren will, was - als „Realität” - schon gegeben scheint.