Suche
Bullshit in der IT? – Bingo!

Bullshit Bingo: Wie man hohle Phrasen in der IT erkennt und vermeidet

Herbert Dowalil

© Shuttertstock / Treter

Jeder kennt ihn, jeder belächelt ihn und jeder benutzt ihn hin und wieder mal als Werkzeug, um unverdient zu Glänzen: Den Bullshit. Er ist in unserer Branche so omnipräsent, dass er eigentlich kaum noch wegzudenken ist. Es muss die Frage erlaubt sein, worum es sich dabei eigentlich handelt und warum gerade wir in der IT so massiv darunter zu leiden haben.

Ich bin mir sicher, dass Sie, genauso wie ich, der Meinung sind, Bullshit zu erkennen, wenn Sie ihn hören. Genauso sicher bin ich mir, dass Sie sich schwer tun werden, wenn ich Sie um eine Definition dafür bitte. Was genau macht Bullshit aus, und an welchen Merkmalen kann man ihn als solchen identifizieren?

Genau da wird es schwierig. Laut dem Philosophen Harry Frankfurt, dessen Buch zum Thema [1] in den USA zum Bestseller wurde, handelt es sich bei Bullshit um eine Aussage, welche die folgenden beiden Merkmale aufweist:

  • Sie zeichnet sich durch eine vergleichsweise inhaltliche Leere aus. Dies wird erreicht durch gezielte Verwendung besonders hohler Phrasen, welche dabei gerne auch zuhauf und in Kombination miteinander eingesetzt werden. Dahinter steckt die Absicht, eine Falsifizierung unmöglich zu machen. Mit anderen Worten: Einen Bullshit erkennt man manchmal schon daran, dass es nicht nur praktisch sondern auch theoretisch schwierig wäre, das Gegenteil zu beweisen.
  • Die Aussage ist anmaßend im Bezug auf die vortragende Person oder ein Produkt oder Konzept, welches durch diese repräsentiert wird.

Damit unterscheidet sich ein Bullshit dezidiert von damit verwandten Konzepten wie:

  • Humbug: Der Begriff Humbug wird auch gerne für hohle Phrasendrescherei benützt, wobei dieser aber nicht unbedingt auch anmaßend sein muss.
  • Arroganz: „Hallo, ich bin der beste Programmierer der Welt“ – so hatte sich mir einmal ein neuer Mitarbeiter bei einem meiner ehemaligen Arbeitgeber vorgestellt. Dies ist zwar in sehr hohem Maße anmaßend, aber im Grunde einfach zu widerlegen, indem man den Kollegen zu einem Programmierwettbewerb schickt. Es handelt sich dabei schlichtweg um astreine Arroganz.
  • Unsinn: In einem Filmklassiker der Monty Pythons wird behauptet, dass man durch Aufblasen von Tüten Erdbeben verhindern könne. Dies ist wiederum nichts weiter als eine vollkommen unsinnige Aussage. Ein Gegenbeweis ist dabei zwar praktisch nicht einfach hinzubekommen, die Aussage lässt sich aber leicht durch eine Reductio ad absurdum theoretisch widerlegen.

Ein Beispiel

Abb. 1: ESB-Kommunikation

Abb. 1: ESB-Kommunikation

Die folgende Argumentation der Enterprise-SOA-Community ist mir bereits mehrfach, oft auf sehr ähnliche Art und Weise formuliert, untergekommen: „Alle Services müssen im Umweg über einen zentralen Enterprise-Service-Bus (ESB) miteinander kommunizieren, um Punkt-zu-Punkt Verbindungen zu vermeiden“. Wenn man dieses Postulat hinterfragen möchte, merkt man schnell, dass dies gar nicht so einfach ist. Zunächst mal muss näher definiert werden, was genau an Punkt-zu-Punkt-Verbindungen schlecht sein soll, und warum zwei Punkt-zu-Punkt-Verbindungen (Service-ESB und ESB-Service) besser sein sollen als nur eine.

Darüber hinaus ist oft nicht näher definiert, was genau die Aufgaben des ESB dabei sein sollen, was genau ein ESB ist (Konzept oder Technologie?) und warum er unbedingt in der Mitte stehen muss. Tatsächlich gilt Logik in der Kommunikationsschicht in der Branche inzwischen klar als Antipattern. In der modernen Microservices-Architektur wird dagegen das Prinzip der Dumb-Pipes-and-Smart-Endpoints propagiert. Wenn aber das Ziel ist, jemandem die Lizenzen für die Verwendung eines ESB zu verhökern, dann wiederum ist dieses Argument geradezu fantastisch.

Diese veraltetete Sichtweise der Softwarearchitektur soll uns aber nicht darüber hinwegtäuschen, dass das Problem Bullshit nach wie vor aktuell ist. Tatsächlich ist die neue Schule der Softwarearchitektur ebenfalls anfällig dafür. Gerade bei aktuellen Hypes werden oft neue Begriffe entwickelt, deren jeweilige Bedeutung sich erst mit der Zeit schärft. Eine Menge an unklaren Begrifflichkeiten ist aber nunmal der ideale Nährboden für Bullshit. Seien Sie also weiterhin wachsam! Fraglich bleibt, warum gerade wir in der IT so unter Bullshit zu leiden haben. Die Ursachen dafür sind aus meiner Sicht:

  • Die IT ist eine noch recht junge Disziplin, in welcher laufend Fachbegriffe erfunden bzw. neu definiert werden.
  • Die IT hat, anders als andere Disziplinen wie Biologie oder Medizin, bis heute keine allgemein anerkannte und sehr gut definierte gemeinsame Sprache entwickelt.
  • Die Konzepte der IT sind oft ausgesprochen abstrakt.
  • IT Projekte sind komplex, und die (Un-)Wirksamkeit diverser Praktiken ist nur schwer nachzuweisen.
  • Mit Software wird oft gutes Geld verdient, während die potentiellen Käufer aber nicht unbedingt ebenfalls aus der IT sind. Damit sind sie anfällig dafür, mit angeblichen Fachbegriffen geblendet zu werden.

DDD Summit 2018
Nicole Rauch

Domain-Driven Design für Einsteiger

mit Nicole Rauch (Softwareentwicklung und Entwicklungscoaching)

Bullshit Poker

Eine Frage, die ich mir schon des öfteren gestellt habe ist, warum Bullshit eigentlich nicht viel öfter hinterfragt und dadurch entlarvt wird? Mir scheint zunächst einmal klar, was die Hauptmotivation für Bullshit ist. Wenn jemand einen Bullshit ausspricht, gleicht das einem Bluff beim Pokern. Wenn es nichts anderes positives über ein Produkt vorzubringen gibt, versucht man davon mit einem Bullshit abzulenken. Man hat dabei kaum etwas zu verlieren, denn ohne den Bluff steht das Produkt sowieso schlecht da. Jemand der den Bullshit potentiell bloßstellen könnte, geht im Gegensatz dazu ausschließlich ein Risiko ein: Für den Fall, dass hinter der vermeintlich hohlen Phrase ein allgemein bekanntes und anerkanntes Konzept steckt, von dem man eigentlich hätte wissen müssen, hat man nämlich seine Unwissenheit diesbezüglich offenbart. Mit anderen Worten:

  • Der Einsatz von Bullshit um die Zuhörer damit zu blenden ist eine Strategie fast ohne Risiko. Wenn das feilgebotene Produkt oder Konzept unsinnig ist macht ein möglicher Glaubwürdigkeitsverlust auch keinen großen Unterschied mehr.
  • Einen Bullshit zu hinterfragen bringt einem kaum Vorteile, während man damit aber sehr wohl das Risiko eingeht sich zu blamieren.

Was hilft dagegen?

Bullshit ist kein Kavaliersdelikt. Es ist nicht völlig abwegig, dass eine Form des Bullshits in einer IT-Abteilung die Kontrolle übernimmt. Tatsächlich habe ich das sogar schon einmal selbst miterleben müssen. Spätestens dann, ist Schicht im Schacht und es wird nicht mehr möglich sein, vernünftige Entscheidungen zu treffen. Bullshit bedeutet nämlich das Ende jedweder Vernunft. Was kann man also gegen Bullshit tun?

  • Erstellen Sie ein Glossar mit den häufig verwendeten Begriffen im Unternehmen. Damit senken Sie auch das Risiko für Missverständnisse, wenn sich die Mitarbeiter über Dinge wie „Services“, „Monolithen“ oder „Architektur“ unterhalten.
  • Sorgen Sie für eine Kultur im Unternehmen, wo es völlig in Ordnung ist, etwas nicht zu wissen. Damit senken Sie das Risiko einer möglichen Blamage.
  • In das Know-How der Mitarbeiter zu investieren ist eigentlich nie verkehrt. Die Kompetenz Ihrer Kollegen fungiert dann quasi als Firewall gegen Bullshit.
  • Halten Sie ab und zu Debattierwettbewerbe unter Ihren Mitarbeitern ab. Das schärft die Wahrnehmung, um tatsächliche Argumente von gefakten zu unterscheiden.
  • Besorgen Sie für sich und Ihre Mitarbeiter Handtücher. Unzählige Reisende, die per Anhalter durch die Galaxis trampen können, was das angeht, eigentlich kaum irren. Besuchen Sie dazu unseren Webshop auf www.embarc.de und wählen Sie aus unserer wohlsortierten internationalen Kollektion etwas passendes aus.

Fazit

Bullshit kann im Extremfall ein Unternehmen in existentielle Probleme bringen. Am Ende des Tages ist es die Kompetenz, von der Mitarbeiter, und deren Mut Unfug aktiv zu hinterfragen, welche das Unternehmen von Schaden durch Bullshit bewahren kann.

Verwandte Themen:

Geschrieben von
Herbert Dowalil
Herbert Dowalil
Herbert Dowalil ist als Softwarearchitekt, Trainer und Berater für die Firma embarc in Wien tätig. E-Mail: herbert.dowalil@embarc.at
Kommentare

Hinterlasse einen Kommentar

1 Kommentar auf "Bullshit Bingo: Wie man hohle Phrasen in der IT erkennt und vermeidet"

avatar
400
  Subscribe  
Benachrichtige mich zu: