Pragmatisch, praktisch, gut

Ein Wort, ein Kopfnicken, Diskussion vorbei. In kaum einem Architektur-Meeting fehlt der Moment, in dem jemand seinen Vorschlag als “pragmatisch” bezeichnet - und der Raum sich merklich entspannt. Wer will schon der Erste sein, der sich gegen Pragmatismus ausspricht? Das klänge nach Dogmatismus, nach jemandem, der die Realität nicht verstanden hat oder sie nicht akzeptieren möchte.

Genau das macht das Wort so wirkungsvoll - und so gefährlich. Es transportiert eine Behauptung (ich habe die Praxis im Blick), ohne dass diese Behauptung je eingelöst werden muss. Zeit, sich anzuschauen, was hinter dieser kleinen Vokabel eigentlich steckt.

Was Pragmatismus wirklich meint

Der Begriff kommt nicht aus dem Nichts. Charles Sanders Peirce, Begründer der philosophischen Pragmatismus-Tradition, hat 1878 in “How to Make Our Ideas Clear” eine strenge Regel dafür aufgestellt, wann ein Konzept überhaupt einen klaren Sinn hat: Wir sollen fragen, welche denkbaren praktischen Wirkungen der Gegenstand eines Begriffs habe. Diese Wirkungen seien dann, so Peirce, “the whole of our conception of the object” - der gesamte Inhalt unseres Begriffs, nicht bloß ein Teil davon.

Das ist anspruchsvoll. Peirce verlangt nicht “irgendeine Wirkung”, sondern eine explizite, prüfbare Liste von Konsequenzen - ein Werkzeug, um schwammige Begriffe in der Erfahrung zu erden.

Vergleichen wir das mit der Floskel “Lass uns das pragmatisch lösen”. Welche praktischen Wirkungen werden dort benannt? Meistens keine. Und genau hier klafft eine Begründungslücke: an der Stelle im Gespräch, an der eine Abwägung von Argument und Gegenargument stehen müsste, steht stattdessen ein Wort, dem niemand widersprechen kann. Die Abwägung fehlt nicht notwendigerweise. Sie hat vielleicht im Kopf des Entscheiders stattgefunden, vielleicht sogar sorgfältig. Sie wird allerdings nicht ausgesprochen. Das Wort verdeckt also nicht das Fehlen einer Begründung, es ersetzt ihre Mitteilung.

Das Ende der Diskussion

Warum funktioniert das so zuverlässig? Drei Denker haben je ein Stück der Antwort geliefert.

Der Psychiater Robert Jay Lifton beschreibt die Wirkung. Er prägte 1961 in “Thought Reform and the Psychology of Totalism” den Begriff des thought-terminating cliché - eine Formulierung, die Diskussionen nicht durch ein Argument beendet, sondern durch eine griffige Phrase. Die komplexesten menschlichen Probleme, schreibt Lifton, werden in kurze, stark vereinfachende, endgültig klingende Sätze gepresst, leicht zu merken und leicht auszusprechen; sie werden zum Anfang und Ende jeder Analyse. Lifton hatte totalitäre Sprachumgebungen im Blick, aber das Muster ist branchenunabhängig: Immer wenn eine Formulierung nicht zum Nachdenken einlädt, sondern es beendet, liegt dieser Mechanismus vor.

Der Politiktheoretiker Ernesto Laclau liefert die Ursache. In “Why do Empty Signifiers Matter to Politics?” (1996) beschreibt er den empty signifier: ein Zeichen, das seine Wirkmacht gerade daraus zieht, dass es kaum festgelegten Inhalt hat, und deshalb ganz unterschiedliche, teils widersprüchliche Anliegen unter sich versammeln kann. Nicht trotz der Leere ist der Begriff stark, sondern wegen ihr.

Jürgen Habermas schließlich benennt die Norm, die dabei gerissen wird. In der “Theorie des kommunikativen Handelns” (1981) beschreibt er, dass wir mit jeder ernst gemeinten Äußerung einen Geltungsanspruch erheben - und dass dieser Anspruch im Zweifelsfall diskursiv eingelöst werden muss, also durch Gründe, die die anderen prüfen können. Wer “pragmatisch” sagt, erhebt genau so einen Anspruch: Mein Vorschlag hält der Praxis stand. Nur wird er nie eingelöst, weil das Wort die Nachfrage, die zur Einlösung führen würde, gleich mit abräumt.

Die Unterscheidung, die daraus folgt, ist die schärfste Diagnose, die ich für dieses Problem kenne: “Pragmatisch” erzeugt Akzeptanz ohne Geltung. Der Raum stimmt zu - aber nicht, weil das bessere Argument überzeugt hätte, sondern weil Widerspruch zu teuer geworden ist. Habermas’ “zwangloser Zwang des besseren Arguments” ist damit auf den Kopf gestellt: Hier zwingt nicht das Argument, sondern seine Abwesenheit.

“Pragmatisch” klingt nach Standpunkt, verlangt aber keinen. Wer widersprechen will, beweist damit schon, dass er nicht pragmatisch denkt - eine Beweislastumkehr, die in der Sache nichts klärt, rhetorisch aber sehr wirksam ist. Andere Kandidaten aus unserem Alltag funktionieren identisch: “sauber”, “skalierbar”, “wartbar”, in Produktdebatten auch “User-Centered”. Niemand widerspricht offen dem Nutzerfokus - weshalb der Begriff jede konkrete Diskussion darüber erstickt, wie die Lösung denn nun aussehen soll.

Verschiedene Ziele, ein Wort

Die Begründungslücke entsteht selten aus reiner Rhetorik. Meistens liegt darunter ein echter, legitimer Zielkonflikt.

Entwickler:innen wollen ein System, das sie und ihre Kolleg:innen in einem Jahr noch verstehen und ändern können - Wartbarkeit, saubere Schnitte, eine Lösung, auf die man stolz sein kann. Das Management verfolgt andere, ebenso legitime Ziele: ein Kundenversprechen einhalten, ein Quartalsziel erreichen, endlich Umsatz mit dem Feature erzielen.

An dieser Stelle lohnt eine unbequeme Selbstprüfung, denn die Asymmetrie geht auch in unsere Richtung: Das Management hat über das Marktfenster in der Regel die besseren Informationen als wir, und wir unterschätzen die Kosten des Zu-spät-Kommens ähnlich systematisch, wie andere die Kosten schlechter Struktur unterschätzen. Ein technisch exzellentes System für einen Markt, der inzwischen gesättigt ist, ist keine gute Architekturentscheidung. Keines der Ziele ist also falsch oder unpragmatisch - das Problem ist, dass sie die Lösung in unterschiedliche Richtungen ziehen.

“Pragmatisch” kaschiert diesen Konflikt, statt ihn zu benennen. Wird ein Vorschlag so bezeichnet, bleibt offen, welchem der konkurrierenden Ziele er dient - und welches dafür stillschweigend zurückstehen muss. Die Architecture Tradeoff Analysis Method (ATAM) setzt genau hier an: Sie bringt Architekten und Stakeholder zusammen, um konkurrierende Qualitätsmerkmale wie Wartbarkeit, Verfügbarkeit oder Time-to-Market explizit gegeneinander abzuwägen, statt sie hinter einem Adjektiv verschwinden zu lassen.

Der Erfahrungsschatz

Ist das nicht unfair gegenüber erfahrenen Architekten mit gutem Erfahrungsschatz? Wer aus echter Erfahrung urteilt, liegt doch oft richtig.

Die Antwort darauf ist einfacher, als der Einwand vermuten lässt: Erfahrung ist kein Problem, unartikulierte Erfahrung ist eins. Wer sein Urteil aus zwanzig Jahren Projektalltag zieht, kann das zugrunde liegenden Erfahrungswerte auch aussprechen. “Pragmatisch ist die Entscheidung, weil wir bei dieser Datenmenge nie in die Nähe des Limits kommen”. Diese kurze Erläuterung kostet kaum mehr Zeit als sie als “pragmatisch” einzustufen, schließt die Begründungslücke aber vollständig. Wer das nicht liefern kann, spricht nicht aus Erfahrung, sondern einem Bauchgefühl.

Ein ähnliches Muster zeigt sich, wenn die Floskel ausgesprochen wird, ohne dass die Person ihren eigenen Vorschlag je wirklich geprüft hat. Nicht aus böser Absicht, sondern weil Entschlossenheit im Moment wichtiger zu sein scheint, als den eigenen Case zu belegen.

Genau das beschreibt Harry Frankfurt in “On Bullshit” (Essay 1986, Buchausgabe 2005). Sein Kriterium ist nicht Wahrheit oder Lüge, sondern die “indifference to how things really are” - die Gleichgültigkeit gegenüber der Frage, ob die eigene Aussage der Wirklichkeit standhält. Bullshitter wollen einen bestimmten Eindruck von sich selbst vermitteln; ob daran etwas wahr ist, ist ihnen nicht wichtig genug, um es zu prüfen. Im Projektalltag trägt oft genau der Wunsch, als Vordenker wahrgenommen zu werden, das Wort “pragmatisch” - nicht Lüge, sondern der Drang, entschlossen zu wirken, bevor der Kurs feststeht.

Aktionismus statt Pragmatismus

Eine zweite Verwechslung tritt auf Managementebene besonders häufig auf: Pragmatismus weicht reinem Handlungsdrang. In der Entscheidungspsychologie heißt das Action Bias - die Tendenz, Handeln dem Nichthandeln vorzuziehen, selbst wenn nichts für ein besseres Ergebnis spricht (Patt & Zeckhauser, 2000).

Der Reflex ist nachvollziehbar: Stillstand fühlt sich nach Führungsversagen an, eine Entscheidung - egal welche - nach Kontrolle und Fortschritt. Genau dann wird “Lass uns das jetzt einfach pragmatisch lösen” zur bequemsten Formel, um Handlungsdruck abzulassen. Hier fehlt nicht Erfahrung, sondern Geduld. Die Begründungslücke bleibt.

Die Kosten

Was diese Verwechslungen teuer macht, ist eine Zeitasymmetrie, die wir uns im Moment der Entscheidung selten klarmachen. Die vermeintlich pragmatische Lösung treffen wir schnell, oft unter Druck. Die Konsequenzen begleiten uns danach nicht Tage, sondern Jahre - in jedem Sprint, in jedem Incident, in jeder Migration, die darauf aufsetzt.

In vielen Entwicklungsteams steht nach einigen Jahren der Wunsch im Raum, endlich den großen Rewrite anzugehen und auf der grünen Wiese neu anzufangen. Das bisherige System wird zum Legacy-System erklärt, weil es zu viele Bugs aufweist, der Code nicht mehr wartbar ist und die Entwickler, die einst dafür zuständig waren, längst maximale Distanz zum Unternehmen aufgebaut haben. Die ersten Schritte bringen Zuversicht, erste Funktionalitäten werden umgestellt, neue Anforderungen umgesetzt, alte Zöpfe abgeschnitten. Doch ein historisch gewachsenes System vollständig abzulösen braucht viel mehr Zeit, als sich das Team meist erträumen mag. Also müssen weiterhin Fixes am Altsystem durchgeführt werden, während gleichzeitig das neue System weiterentwickelt wird. Irgendwann kommt das Team wieder am selben Punkt an: Auch im neuen System tauchen neue Bugs auf, manche der alten Probleme lassen sich auch hier nicht lösen, und am Ende sind alle Stakeholder enttäuscht, weil das Vorhaben viel teurer wurde als gedacht. Fred Brooks hat dieses Muster schon 1975 in “The Mythical Man-Month” als Second-System-Effekt beschrieben: Ein zweites System wird fast immer größer, langsamer und fehleranfälliger geplant als nötig, weil das Team dabei am liebsten alles korrigieren will, was am ersten System je gestört hat. Was im Altsystem vielleicht etwas Gehirnschmalz und einige Monate Umbauarbeit gekostet hätte, wird so zu einem jahrelangen Projekt, das am Ende am selben Punkt landet wie das ursprüngliche Legacy-System.

Ökonomisch ist dieses Muster gut untersucht. Der Present Bias - die Verhaltensökonomie modelliert ihn über hyperbolische Diskontierung (Laibson 1997; O’Donoghue & Rabin, “Doing It Now or Later”, 1999) - beschreibt genau diese Schieflage: Wir gewichten einen unmittelbaren Vorteil überproportional gegenüber einem größeren, aber späteren Nachteil, selbst wenn wir bei ruhiger Abwägung anders entscheiden würden. Ruhe im Meeting und ein zufriedener Stakeholder wiegen schwerer als die diffuse, weit entfernte Aussicht auf Wartungsaufwand.

Ward Cunningham hat dafür 1992 in seinem OOPSLA-Erfahrungsbericht “The WyCash Portfolio Management System” die Metapher der technischen Schulden geprägt. Wichtig ist dabei ein Detail, das in der Rezeption meistens untergeht: Cunningham meinte damit ausdrücklich keinen schlechten Code. Er hat sich später sogar explizit dagegen verwahrt. Seine Aussage war: “A little debt speeds development so long as it is paid back promptly.” Schulden aufnehmen ist ein legitimes Instrument - solange wir wissen, dass wir welche aufnehmen, und einen Tilgungsplan haben.

Und genau das ist der Punkt, an dem sich der Kreis schließt: Eine bewusst aufgenommene Schuld ist gute Architekturarbeit. Eine unbenannte ist ein Kredit, von dem die Zinsen uns erst Jahre später im Betrieb auffallen.

ADRs als Gegenmittel

Wie schließen wir nun die Begründungslücke im Projektalltag? Michael Nygard hat 2011 in “Documenting Architecture Decisions” das Format der Architecture Decision Records (ADR) vorgeschlagen, weil in agilen Projekten die Beweggründe hinter wichtigen Entscheidungen oft nur im Kopf der Entscheidenden existieren und für den Rest des Teams unsichtbar bleiben. Ein ADR zwingt uns, explizit zu machen, was sonst unausgesprochen bleibt: den Kontext, die betrachteten Alternativen, die Entscheidung selbst und - besonders wichtig - ihre positiven und negativen Konsequenzen.

Der Hebel liegt im letzten Punkt. Ein ADR verlangt nicht, eine Entscheidung im Nachhinein zu rechtfertigen, sondern Alternativen und ihre Folgen von Anfang an nebeneinanderzustellen - genau das, was Peirces Maxime verlangt. Es ist der Ort, an dem der Geltungsanspruch eingelöst wird - schriftlich, nachprüfbar und unabhängig davon, wer im Meeting den längeren Atem hatte. Ein Vorschlag, der als “pragmatisch” durchgewinkt werden soll, aber nirgends dokumentiert, welche Alternativen verworfen wurden und warum, hält dieser Struktur schlicht nicht stand. Und wer die Konsequenzen aufschreibt, hat die technische Schuld damit automatisch benannt, statt sie nur aufzunehmen.

Das macht Entscheidungen auch verhandelbar. Solange ein Vorschlag nur als Adjektiv im Raum steht, lässt er sich kaum angreifen, ohne dass man persönlich wirkt. Als Text mit benannten Alternativen verschiebt sich die Diskussion von der Person auf die Sache - wir widersprechen einem Kriterium, nicht mehr einer Haltung. Im besten Fall gewinnen dabei alle: Wer als erfahrener Architekt seine Beweggründe offenlegt, macht die eigene Erfahrung für andere anschlussfähig. Neue Kolleg:innen können an dokumentierten Entscheidungen nachvollziehen, wie erfahrene Köpfe abwägen, und daran wachsen.

Der zweite Effekt betrifft die Zeitasymmetrie: Ein ADR ist auch für unser zukünftiges Ich geschrieben. Wenn wir in drei Jahren vor den zwei Systemen stehen, die parallel entwickelt wurden, und uns fragen, was wir uns damals gedacht haben, gibt uns das Dokument die Antwort - und oft zeigt sich, dass die Entscheidung unter den damaligen Bedingungen völlig nachvollziehbar war.

Der Anfang eines Satzes

“Pragmatisch” sollte nie das Ende eines Satzes sein, sondern höchstens sein Anfang. Auf “das ist die pragmatische Lösung” folgt immer eine berechtigte Rückfrage: was meinst du damit konkret? - Time-to-Market, Betriebskosten, kognitive Last im Team, Wartbarkeit in drei Jahren? Nenne die praktischen Wirkungen, sonst ist der Begriff leer. Um diese Rückfragen im Meeting nicht jedes Mal neu stellen zu müssen, können sie in ein ADR-Template ausgelagert werden - dort verlangt die Struktur die Antwort ganz von selbst.

Denn richtig verwendet ist “pragmatisch” eine der stärksten Kategorien, die wir in der Architekturarbeit haben. So klingt sie:

“Pragmatisch heißt hier: Wir nehmen die Kopplung zwischen Checkout und Inventar bewusst in Kauf, weil das Marktfenster in sechs Wochen zu ist. Der Preis ist, dass beide Teams bis zur Entkopplung gemeinsam deployen müssen. Das steht im ADR, und wir planen die Tilgung für Q3.”

Das ist derselbe Vorschlag wie vorher. Nur ohne Begründungslücke. Er ist angreifbar geworden - und genau deshalb belastbar.

Entwertet wird also nicht das Wort, sondern nur sein Missbrauch als rhetorischer Nebelwerfer. Und ja: Das gilt auch für mich selbst, wenn ich das nächste Mal versucht bin, eine Entscheidung mit dieser einen bequemen Vokabel abzukürzen.

Quellen

• Charles S. Peirce, “How to Make Our Ideas Clear”, Popular Science Monthly (1878);
• Robert J. Lifton, “Thought Reform and the Psychology of Totalism” (1961), Kap. 22;
• Ernesto Laclau, “Why do Empty Signifiers Matter to Politics?”, in: Emancipation(s) (1996);
• Jürgen Habermas, “Theorie des kommunikativen Handelns” (1981), Bd. 1, zu Geltungsansprüchen und ihrer diskursiven Einlösung;
• Kazman, Klein, Barbacci, Longstaff, Lipson, Carriere, “The Architecture Tradeoff Analysis Method”, ICECCS (1998);
• vertiefend Clements, Kazman, Klein, “Evaluating Software Architectures” (2002);
• Harry G. Frankfurt, “On Bullshit”, Raritan (1986), Buchausgabe Princeton University Press (2005);
• Patt & Zeckhauser, “Action Bias and Environmental Decisions”, Journal of Risk and Uncertainty (2000);
• David Laibson, “Golden Eggs and Hyperbolic Discounting”, QJE (1997);
• O’Donoghue & Rabin, “Doing It Now or Later”, American Economic Review (1999);
• Ward Cunningham, “The WyCash Portfolio Management System”, OOPSLA (1992);
• Frederick P. Brooks Jr., “The Mythical Man-Month: Essays on Software Engineering” (1975), Kap. “The Second-System Effect”;
• Michael Nygard, “Documenting Architecture Decisions” (2011)

Auf Mastodon teilen