Als die Softwareentwicklung eine Geisteswissenschaft wurde

Die Klausur, die mir das Falsche beibrachte

Ich habe Informatik studiert, im Nebenfach Soziologie. Meine schlechtesten Noten holte ich in Soziologie, und ich habe Jahre gebraucht, um zu verstehen, warum.

Die Klausuren waren Multiple Choice. Vier, fünf Antwortmöglichkeiten, und die Wortvariationen zwischen ihnen waren so gering, dass sich der Sinn kaum änderte. Trotzdem war eine richtig und der Rest falsch. Geprüft wurde nicht, ob man verstanden hatte, wie Gesellschaften funktionieren. Geprüft wurde, ob man auf der Ebene einzelner Wörter erkennt, von welchem Soziologen ein Satz stammt.

Das ist kein Versagen der Soziologie. Es ist die Geisteswissenschaft, wie sie ist: eine andere Disziplin mit einem anderen Prüfstein, oder besser ganz ohne den Prüfstein der Naturwissenschaften. Nichts von außen entscheidet den Streit; man kann kein Experiment durchführen, das den einen Denker bestätigt und den nächsten widerlegt. Was man also wirklich beherrschen lernt, ist die Landkarte: welche Schule was vertritt, wo zwei Denker sich trennen, wie man einen Satz auf der Ebene eines einzelnen Wortes einordnet. Die Modelle sind Teilmodelle, jedes greift nur manchmal, und die Kunst besteht darin, sie auseinanderzuhalten. Das ist echte geistige Arbeit. Aber es ist eine Kunst des Unterscheidens zwischen Modellen, nicht des Hervorbringens eigener Gedanken: Man lernt, die Ideen anderer mit messerscharfer Präzision zu trennen, ohne je eine eigene beisteuern zu müssen.

Ich erzähle das, weil die Softwareentwicklung früher das Gegenteil war. Und weil sie gerade leise denselben Weg nimmt.

Früher gab es eine einzige harte Frage

Dein Code muss funktionieren. Das war das Kriterium. Idealerweise schnell, idealerweise sicher, je nach Anwendungsbereich. Aber unter allem lag ein Test, den die Realität selbst abnahm: Es läuft, oder es läuft nicht. Du konntest jung sein, arrogant, autodidaktisch, unbequem; egal. Der Compiler und der Ausfall um drei Uhr nachts kümmerten sich nicht um deinen Ruf. First Principles, geprüft an der Wirklichkeit.

Dann fingen wir an, Design Patterns und „sauberen Code“ zu proklamieren. Nicht als Werkzeuge, sondern als Tugend. Auf der nie wirklich bewiesenen Annahme, dass diese Regeln bessere Wartbarkeit und weniger Fehler bringen. Mag sein. Manchmal stimmt es. Doch bemerkenswert, was dabei mit dem Kriterium geschah: Aus „funktioniert es“ wurde „hast du es so umgesetzt, wie es im Buch steht“.

Das ist eine andere Art von Frage. Sie hat einen Kanon. Sie hat Schulen. Sie hat Leute, die Uncle Bob auswendig zitieren und dir erklären, deine tadellos laufende Funktion sei falsch, weil sie vier Parameter hat statt drei. Das Maß wanderte von der Welt in den Text.

Cargo-Kult, benannt im Jahr 2000

Steve McConnell hat das vor einem Vierteljahrhundert kommen sehen. 2000 übertrug er in der IEEE Software Richard Feynmans „Cargo-Kult-Wissenschaft“ auf unser Fach und prägte den Begriff Cargo-Cult Software Engineering: Organisationen, die die sichtbaren Formen erfolgreicher Teams nachahmen (die Prozesse, die Patterns, die Meetings), ohne zu verstehen, warum diese Formen bei irgendjemandem je funktioniert haben. Das Erkennungszeichen, schrieb McConnell, ist die Begründung: „Das haben wir schon immer so gemacht“ oder „unsere Standards verlangen das“. Gründe, die auf ein Regelwerk zeigen statt auf ein Ergebnis.

Das ist die ganze Krankheit in einem Satz. Sobald man eine Praxis nicht mehr damit begründen kann, was sie liefert, sondern nur noch damit, was die Regeln fordern, hat man die Ingenieurskunst verlassen und die Schriftauslegung betreten.

Dann machte Agile aus „get it done“ eine Zeremonie

Über Velocity-Theater habe ich an anderer Stelle geschrieben, also fasse ich mich kurz. Agile begann als Korrektur: funktionierende Software ausliefern, schnell Rückmeldung holen. Dann fraß die Branche es auf. Aus dem Standup wurde ein Status-Ritual. Aus der Retro eine Therapiestunde. Aus Story Points eine Währung, die niemand in Geld oder Zeit umrechnen kann. SAFe machte aus dem Ganzen ein Organigramm. Das Manifest wurde zur Religion und die Zertifizierungsindustrie zu ihrer Kirche, die den Ablass im Zwei-Tage-Takt verkauft.

Und ein feinerer Wandel kam mit: Das Ziel verschob sich leise von wird die Arbeit fertig zu wie geht es dem Team damit. Das sind nicht dieselben Fragen. Beide zählen, aber nur eine ist die Aufgabe.

Das Problem der Bequemen, die falsch liegen

Jetzt wird es unpopulär. Der herrschende Rat lautet, den „brillanten Kotzbrocken“ zu entfernen, um die psychologische Sicherheit des Teams zu schützen. Manchmal ist das genau richtig; niemand arbeitet gut in einem Raum, vor dem er Angst hat, und Talent ist kein Freibrief für Grausamkeit.

Aber eine Kultur, die nur auf Bequemlichkeit optimiert, hat einen Fehlermodus, den niemand gern benennt: Sie schützt den Angenehmen, der falsch liegt, vor dem Unbequemen, der recht hat. Sie stellt Dazugehören über Richtigsein. Und ausgerechnet das Kriterium, das früher jeden Streit entschied („funktioniert es“), ist das, das den Leuten unbequem ist, weil es sie öffentlich widerlegen kann.

Man kann auf Anstand bestehen und trotzdem die harte Frage voranstellen. Der Filter, der zählt, lautet: Hast du recht, und lieferst du? „Sitzt es sich angenehm neben dir?“ kommt danach. Verdreht man die Reihenfolge, optimiert man ein Soziologie-Seminar, kein Entwicklungsteam.

Das sauberste Freiluftexperiment der Branche

Man muss das nicht theoretisch ausfechten. Die Autoindustrie hat das Experiment für uns gemacht.

Volkswagen gründete CARIAD 2020, um das Rennen um das softwaredefinierte Auto zu gewinnen. Nach den eigenen Zahlen wurde es ein Desaster: berichtete operative Verluste von über 7,5 Milliarden Dollar in drei Jahren, die Software-Plattform 1.2 um 16 bis 18 Monate verspätet und den Porsche Macan sowie den Audi Q6 e-tron blockierend, die nächste Plattform Richtung 2027 oder 2028 verschoben. Eine im Konzern beauftragte McKinsey-Prüfung fand Berichten zufolge ein Dutzend Probleme, allen voran, dass die Beteiligten schlicht nicht miteinander kommunizieren konnten. Meetings, PowerPoint, Organigramm, Altlast: die volle Zeremonie.

Tesla, ein paar Straßen weiter, ist die Software-first-Firma, der jetzt alle hinterherlaufen. Flach, ergebnisbesessen, unbeeindruckt vom Ritual. Man kann vieles an der Führung dort unsympathisch finden und trotzdem das Muster erkennen: Die Organisation, die weiter fragte „liefert es, funktioniert es“, hängte die ab, die den Prozess perfektionierte. Der Produktivitätsunterschied ist ein Unterschied bei den First Principles, kein Ritual-Unterschied.

Die Zeremonie kommt auch für die KI

Agentisches Programmieren ist ein echter Produktivitätssprung. Wir sehen es jeden Tag; der Agent schreibt, der Mensch orchestriert, und der Durchsatz ist unübersehbar.

Und die Zeremonie bildet sich längst darum. „KI-Governance-Ausschüsse“ und „Prompt-Governance“ sind inzwischen feste Begriffe: Freigabestufen, Versionierung und Auditierung von Prompts, Kontrollen mit Zuordnung zum EU AI Act und zu ISO 42001, dazu Zertifikate im Prompt Engineering zum Einsammeln. Manches davon ist wirklich nötig: Sicherheit und Compliance sind nicht optional. Aber darunter läuft derselbe Reflex: Aus einer Fähigkeit wird ein Prozess, aus dem Prozess ein Ausschuss, aus dem Ausschuss ein Zertifikat. Berichte beschreiben bereits Unternehmen, die monatelang an KI-Governance-Rahmenwerken gebaut haben, nur um festzustellen, dass sich nichts geändert hat.

Stapelt man genug davon auf einen Faktor drei, ist man wieder bei Faktor eins, mit mehr Meetings. Die Produktivität ist real; die Lust, sie wegzubürokratisieren, ist es auch, und sie ist besser finanziert.

Die einzige Verteidigung ist die alte Frage, unerbittlich gestellt: Läuft das Ding, ist es schnell, ist es sicher, ist es ausgeliefert? Alles, was sich davor nicht rechtfertigen kann, ist Zeremonie, so vernünftig es auch klingt.

Was wir tatsächlich tun

Deshalb ist unser Hard-Agile eine Verweigerung, keine Methode mit Logo. Wir messen Durchsatz, Zykluszeit und Fluss (was ausgeliefert wird und wie schnell), weil das die Zahlen sind, die die Realität prüft, nicht die, die ein Team sich selbst gibt. Wir sind nicht da, um Ihre Rituale abzuhalten oder Ihre Patterns zu benoten. Wir sind da, um die Sache zum Laufen zu bringen, sie schnell zu machen und zu gehen, wenn Ihr Team sie so halten kann.

Software war nie als Geisteswissenschaft gedacht. Sie hatte das Seltenste, was ein Fach haben kann: einen harten, ehrlichen, äußeren Test, ob man recht hatte. Das ist es wert, verteidigt zu werden. Alles andere ist Deutung.