Ich habe dank Adorno über Explikation – oder wie Adorno es nennt: Entfaltung – und Definition nachgedacht. Wer in Projekten arbeitet, kennt das Problem des Requirements Engineering, auch wenn der Begriff vielleicht nie genannt wird. Es gibt auch den Begriff Requirements Gathering, also das Aufsammeln von Anforderungen, aber der trifft den Kern der Sache nicht, denn Anforderungen sind nie so klar beim Projektstart, dass man sie einfach in ein Körbchen einsammeln könnte. Auch der Begriff Anforderungsanalyse geht noch an der Sache vorbei. Analysieren kann man ja nur etwas schon Gegebenes. Requirements Engineering ist der viel treffendere Begriff, denn Anforderungen müssen richtiggehend erst geschaffen werden.
Jedes Projekt bezieht sich auf eine Fachdomäne und jede Fachdomäne hat eine eigene Sprache mit eigenen fachspezifischen Begriffen. Ein Werkzeug, das man deshalb versucht ist im Requirements Engineering einzusetzen, ist die Begriffsdefinition. Und jetzt kommt Adorno und sagt: Die nachträgliche Definition von Begriffen ist unmöglich. Definitionen schaffen Begriffe. Das funktioniert in der Mathematik ganz hervorragend, weil man sich dort ja nicht mit realen Dingen beschäftigt, sondern wirklich Dinge erschafft. In anderen Feldern, in Feldern, die mit der Realität verbunden sind, findet man aber Dinge schon vor. Wenn man nachträglich etwas definiert, das vorher schon da war, dann trifft man nie ganz ins Schwarze.
Begriffe können selten definiert werden, aber Begriffe können immer expliziert werden. Adorno ist der Meister der Konstellation. Das ist die Darstellung von Sachverhalten anhand von Explikationen, also von Momenten, die an einer Sache beteiligt sind. Explikation, also Entfaltung, bedeutet, die wesentlichen Momente eines Begriffs darzustellen. Ein Moment ist etwas, das den Begriff in eine bestimmte Richtung drückt. Als Beispiel sei hier kurz auf den Begriff des Preises eingegangen. Man kann den Begriff Preis gar nicht fassen, ohne Begriffe wie beispielsweise Preisvergleich anzuführen. Ohne Vergleich löst sich ein Preis nämlich in Luft auf. Der Preis enthält als Moment also einen Bezug auf einen Markt. Für viele Anwendungen wird der Preis zunächst gar nicht so weit entfaltet werden müssen. Der Preis, das ist halt das, was auf dem Preisschild steht. Selbst dort ist das Moment Markt trotzdem vorhanden. Beim Requirements Engineering für einen Onlineshop wird man vielleicht anfangen mit dem Preis, wie er auf dem Preisschild steht, als unveränderbares Attribut eines Produktes. Aber selbst der unspektakulärste Onlineshop wird seine Preise anpassen wollen. Als funktional denkender Softwarearchitekt wird man mit Recht vermeiden wollen, dass man die Preise völlig unkontrolliert einfach ändern kann. Event-Sourcing ist meistens eine gute Idee und so auch hier. Wahrscheinlich möchte ich doch später mal wissen, wie ein Preis aussah zu einem bestimmten Zeitpunkt in der Vergangenheit. Und schon hat sich der Markt als Moment in den Preisbegriff eingeschlichen, denn das Hoch und Runter des Preises, das aus dem Event-Log ableitbar ist, zeichnet gewisse Aspekte des Marktes nach. Wenn man jetzt noch weiter entfaltet, schreibt man Das Kapital von Marx.
Dass man mit einer Definition nie ganz ins Schwarze trifft, heißt nicht, dass die Definition keinen Wert hat. Zum einen muss man irgendwann ja mal was Programmieren und Programmieren ist Definieren. (Es wäre interessant, darüber nachzudenken, ob Programmieren notwendigerweise definitorisch sein muss, oder ob ein entfaltendes Programmieren möglich wäre. Ein sauberer deklarativer Programmierstil, wie er beispielsweise von der funktionalen Programmierung angestrebt wird, ist dabei übrigens nicht mehr oder weniger definitorisch als das übliche imperative Drauflosprogrammieren. Die Definition steckt auch im Willy-Nilly-Java-Stil, sie kommt nur nicht direkt ins Bewusstsein.) Dem Zwang zur Definition kann man sich also nicht bis in alle Ewigkeit entziehen. Das muss kein Grund zur Verzweiflung sein. Oft trifft man eine Domäne an, wo die Begriffe ganz furchtbar vertrackt und verschlungen sind und dann tut ein Softwareprojekt manchmal allein dadurch gut, dass man gezwungen ist, ein wenig aufzuräumen. Man sollte dann an manchen Stellen sagen: Wir definieren diese Sache jetzt mal so und so; ich weiß, das trifft den Begriff nicht exakt so, wie er heute verwendet wird, aber ich denke, Sie alle sollten ihn so verwenden, denn das macht die und die Punkte deutlich einfacher verständlich. Allerdings bis man zu einer solchen frischen Definition gelangt, einer Definition, die mit etwas Anstrengung doch von allen angenommen wird, auch das erfordert viel Explikation im Voraus.
Der Titel des Essays benennt den dialektischen Prozess, aber der Begriff Dialektik trat bisher noch gar nicht auf. In einer wilden Selbstreferenzialität lässt sich auch der Begriff Dialektik nicht definieren, nur entfalten, und gleichzeitig sind genau die Entfaltung und die oben beschriebenen Zwänge der Momente ein wesentliches Moment der Dialektik. Ein weiteres wesentliches Moment der Dialektik ist der Widerspruch: Wenn man den Zwängen eines Begriffs konsequent folgt, ergeben sich Widersprüche. Der Preis führt irgendwann zu einer Analyse der kapitalistischen Gesellschaft und damit zu einer großen Konstellation von Widersprüchen. Und auch der Widerspruch ist wichtig fürs Requirements Engineering. In der Vergangenheit war das für mich oft schwer zu verkraften: Hä, Leute, seht ihr nicht, dass alles, was ihr da macht, in einen einzigen katastrophalen Widerspruch mündet? Das liegt aber nicht daran, dass die Beteiligten alle blöd sind, sondern das liegt im konsequenten Denken.
Mein Verständnis von Dialektik bezieht sich hier über den Umweg über Adorno natürlich auf Hegel. Anders als das vulgäre Hegel-Verständnis sagt, lassen sich die Widersprüche nicht einfach per Synthesis auflösen. Die Widersprüche lassen sich nur weiter konsequent verfolgen zu immer tieferen Widersprüchen. Als jemand, der mit Requirements Engineering und Programmieren auch Geld verdienen muss, kann man diese Vertiefung irgendwann abbrechen und es als Erfolg verbuchen, wenn man bei einer allgemeinen Systemkritik angelangt ist. In einem Projekt ist vonseiten eines Kunden fast wortwörtlich der Satz gefallen: Ja gut, also wenn wir das natürlich so konsequent denken wollen, dann können wir alle unsere Jobs kündigen und in den Wald ziehen. Es zog natürlich niemand in den Wald. Der Gedanke wurde verdrängt. Aber die Begriffe der Domäne waren jetzt weit genug entfaltet, um bisschen Software draufwerfen und geil den Unternehmensprofit erhöhen zu können.