Kann man das glauben? IT-News kritisch lesen
Einleitung
Eat jelly doughnuts and lose twenty pounds a day
Hear the story of the man born without a head
And top psychics all agree // That the telephone company
Will have a brand new service that lets you talk to the dead
— Weird Al Yankovic, Midnight Star (1984)
1984 fühlt sich heute an wie ein anderes Zeitalter. Als der US-Comedian und Sänger Weird Al Yankovic diesen Song geschrieben hat, musste man noch zum Zeitungskiosk oder an die Supermarktkasse, um an die Schundblätter mit solchen Enthüllungen zu kommen. In vielen Ländern hatten noch die nationalen Telefongesellschaften das Sagen, die ihre Monopole mit kundenfreundlichen Zusatzdiensten zu verteidigen versuchten.
Sprung ins Jahr 2026: Die Medienlandschaft schaut anders aus. Interessante News holt man sich heute auf Social Media wie Facebook und X, früher Twitter, oder auf Abo-Plattformen wie Medium und Substack. Und daneben jede Menge News, die einfach nur … interessant sind.
Gleich geblieben ist der atemlose Ton der Schlagzeilen. Heute heißt er Clickbait, weil sich die Monetarisierung geändert hat. Die IT-Branche ist dabei kein Stück besser als jedes andere Fachgebiet.
Verständlich ist es schon. Jeder IT-Projektmanager, Systemarchitekt und Softwareentwickler sucht die "Silver Bullet", mit der die Arbeit pünktlich, im Budget und mit zufriedenen Kunden fertig wird. Einfach Datenbank X einsetzen, in Sprache Y neu schreiben, Library Z ausprobieren. Verlockend. Vielleicht nicht ganz so verlockend wie Krapfen, aber nah dran.
Die Rechnung ist einfach. Stimmt die Geschichte, kostet jeder Monat ohne Umstieg Zeit und Ressourcen. Stimmt sie nicht, kostet der Umstieg Zeit und Ressourcen und schiebt ein ohnehin wackliges Projekt in den Titanic-Modus. Alles hängt daran, ob die Behauptungen halten.
Nur, wie erkennt man das?
Abdeckung
Kurz zurück zu den Krapfen. 10 Kilo am Tag ist vermutlich "ein Tippfehler", 1 Kilo pro Woche wäre dagegen eine gesunde Abnehmrate. Welche Belege wollen wir sehen, bevor wir das ausprobieren? Vermutlich eine medizinische Studie, am besten randomisiert und kontrolliert. Doppelblind wird sie nicht sein, weil es keine Placebo-Krapfen gibt. Dafür eine gute Mischung an Probanden in beiden Gruppen, und auf jeden Fall ein paar Leute in unserer eigenen Alters-, Gewichts- und Lebensstilklasse.
Worum es dabei eigentlich geht, ist Wiederholbarkeit. Jemand hat X gemacht und das erstaunliche Ergebnis Y erzielt. Bevor ich mir die Mühe mache, will ich wissen, ob ich eine Chance auf dasselbe Ergebnis habe. Der Effekt muss sich bei mir wiederholen lassen.
Mein Vertrauen darauf steigt, wenn das Experiment fair war, lang genug gedauert und verschiedene Umstände abgedeckt hat. Klingt die Situation zu anders als meine eigene, wird es zum Würfelspiel, ob die Änderung hilft oder schadet.
Softwareprojekte sind per Definition einzigartig. Jedes hat eigene Umstände, schon wegen der Beteiligten, des Orts und des Zeitrahmens. Ein Projekt zu wiederholen ist eine absurde Idee. Man steigt nie zweimal in denselben Fluss, wie der ionische Naturphilosoph Heraklit angemerkt hat.
Wiederholbar sind die Bestandteile: die Datenbanken, die Development-Frameworks, die Programmiersprache, die Algorithmen, sogar die Domänenmodelle. Darüber lässt sich vernünftig etwas lernen, und das wandert dann in den eigenen Werkzeugkasten.
Wie bei der medizinischen Studie hätten wir gern eine gute Mischung an Projekten, die einen bestimmten Bestandteil erfolgreich einsetzen. Das entspricht der guten Mischung an Krapfenessern. Wie viele? Stark vereinfacht nach dem zentralen Grenzwertsatz etwa dreißig. Also müssten dreißig unabhängige Berichte über Projekte, die mit Datenbank X erfolgreich geliefert haben, reichen?
Damit verschiebt sich die Frage auf die Geschichte des Erfolgs. Wir wollen Datenbank X einsetzen, weil sie den Erfolg wesentlich mitgetragen hat. Das ist die Rechtfertigung dafür, unser Toolkit zu erweitern. Dafür müssen wir aber sicher sein, dass es wirklich die Datenbank war und nicht etwas anderes. Den Erfolg wollen wir schließlich replizieren.
Illusionen des Erfolgs
Manchmal ist eine einfache Erfolgsgeschichte nur eine Illusion. Sie erzählt den Erfolg auf die eine Art, aber es gab weitere Ursachen, die nicht vorkommen. Das ist wichtig, weil man alle Ursachen replizieren muss und nicht nur die, die die Geschichte nach vorne stellt. Fehlt eine davon, ist die eigene Situation zu anders, und die Ergebnisse halten womöglich nicht. So eine Geschichte wirkt wie eine Fata Morgana: Von Weitem sieht alles großartig aus, und wenn du näher kommst, ist da nichts. Trocken im Hals bleibst du trotzdem zurück.
Auf eine Illusion des Erfolgs hinzuweisen wirft niemandem Lügen vor. Fata Morgana heißt hier nur: Die kausale Geschichte ist komplizierter als dargestellt. Es gab andere Aspekte, die nicht das Gewicht bekommen haben, das sie vielleicht hatten. Und es gibt alternative Erklärungen, die mit Datenbank X womöglich gar nichts zu tun haben.
Eine berühmte Illusion des Erfolgs geht auf den Survivor Bias zurück. All die Firmen, die mit Datenbank X gescheitert sind, sind nicht mehr da, um darüber zu bloggen, auf Branchenkonferenzen zu präsentieren oder Videos zu machen. Das verzerrt die Ergebnisse, und es ist besonders schade, weil gerade ihre Lessons Learned aufschlussreich gewesen wären. Die Sache mit dem Survivor Bias ist komplexer, als sie hier Platz hat, und bekommt einen eigenen Blogpost.
Für manche dieser Illusionen ist die IT-Branche besonders anfällig. Es lohnt sich, sie der Reihe nach anzuschauen, weil der Blick dafür danach schärfer ist.
Selection Bias: das Atypische verallgemeinert sich nicht
Das ist die Geschichte "Wir haben X eingeführt und damit Y verbessert". Sie spricht an, weil jeder Y verbessern will. Zur Illusion wird sie, wenn Y gar nicht wegen X besser wurde, sondern wegen etwas ganz anderem.
Hat ein gewöhnliches Team X in einer gewöhnlichen Situation innerhalb einer gewöhnlichen Organisation eingeführt, kommt das der randomisierten Studie so nahe, wie wir es erwarten dürfen. Aber wenn Organisation, Situation oder Team ausgewählt waren?
Gehen wir es der Reihe nach durch.
Erste Sorge: Vielleicht war die Organisation außergewöhnlich. Klingt nach einem Management, das Engineering-Kultur unterstützt und bereit ist, Ressourcen in Adoptions-Experimente zu stecken. Das Budget ist freigegeben worden, ohne dass jemand wusste, ob Y sich überhaupt verbessern würde. Im Nachhinein wirkt das weise.
Zweite Sorge: Vielleicht war die Situation außergewöhnlich. Vielleicht war das Team von den üblichen Ablenkungen aus Bug-Crawls, Deadlines und Meetings befreit.
Dritte Sorge: Vielleicht war das Team außergewöhnlich. Vielleicht sind die besten Architekten, die Lead Developer und die talentiertesten Interns zusammengezogen worden. Die Sorte Leute, die Y auch verbessert hätten, indem sie alles in objektorientiertem Cobol neu schreiben.
Und vielleicht war die Teamgröße außergewöhnlich. Hyperscaler können Teams aufbieten, die sich normale Firmen nicht leisten.
Damit "X einführen verbessert Y" bei deinem Team funktioniert, müssen diese Adopter deinem Team ähnlich sein. Sonst bleibt der Verdacht, dass ihr Dream-Team-Status, ihre Situation oder ihr Rückhalt im Konzern den Erfolg getragen hat.
Natürliche Varianz unterschätzen
Jede Situation ist ein neuer Würfelwurf. Manche sind großartig (grün), manche furchtbar (rot), die meisten einfach durchschnittlich (gelb). Das ist natürliche Varianz.
Weil Menschen gern glauben, sie hätten die Kontrolle, unterschätzen sie, wie viel von dem, was passiert, einfach diese Varianz ist. Die Rückkehr zum Durchschnitt nach einer Ausnahme heißt Regression zur Mitte. Weil die Enden der Verteilung selten sind, bringen sie die Zuschreibung durcheinander, sobald man Abfolgen von Situationen betrachtet.
Vom schlechten Ende her ist das der Coach's Fallacy. Manche Coaches glauben gern, dass ihr Team nach einer schwachen Leistung besser spielt, wenn sie es anschreien. Die Statistik sagt: Das Team hätte ohnehin durchschnittlich gespielt. In unserer Zeichnung folgt auf eine Rot-Pfeil-Situation eine Gelb-Pfeil-Situation. Das passiert irgendwann zwangsläufig, weil Rot ungewöhnlich und damit selten ist. Und weil Gelb weniger schlecht ist als Rot, sieht es nach Verbesserung aus. Ohne jedes Zutun wäre die Situation von allein zum Durchschnitt zurückgekehrt.
In der IT ist das die Geschichte "Nach dem schlechten Ereignis X haben wir …". Der Rot-Pfeil ist der Aufhänger der ganzen Erzählung. Alles, was nach dem "wir" kommt, hat höchstwahrscheinlich nur den Normalzustand wiederhergestellt.
Die Gegenrichtung heißt Winner's Curse: Der Grün-Pfeil, das außergewöhnlich Gute, tritt ein. Nur ist Grün genauso selten wie Rot und Gelb das Normale, also lässt sich der Erfolg nicht reproduzieren. Ein One-Hit-Wonder.
In der IT ist das die Geschichte "Für Kunde X haben wir …". Es gab eine glorreiche Konstellation, in der alle Teile genau richtig zusammengekommen sind. Ob sich das je für jemand anderen verallgemeinern lässt?
Zu kleine Stichprobe vs Erfahrung
Für die nächste Fata Morgana brauchen wir ein etwas komplexeres Beispiel. Die Grafik zeigt einen Strom von Ereignissen über die Zeit, sagen wir Käufe auf einer Website, aus Sicht des Teams, das sie betreibt. Die Zeit läuft von links nach rechts.
Oben kommen Besucher, Requests und Queries im durchschnittlichen Takt. Dann gibt es Phasen mit ungewöhnlichem Traffic. Manche haben in der Geschäftswelt einen Namen, etwa Quartalsende oder Black Friday. Manche sind kulturell und haben in der IT keinen eigenen Namen: Super Bowl, religiöse Feiertage, Schulbeginn. Und dann sind da die üblichen Outages und DevOps-Desaster.
All das zusammen entscheidet, ob die Website die beabsichtigte Performance liefert. Ob man versteht, wie sie sich verhält, hängt stark davon ab, welche Zeitscheibe man sich anschaut. In diesem Ereignisstrom gibt es mehrere Scheiben unterschiedlicher Breite, in denen alles großartig ausschaut. Und es gibt mehrere Phasen, in denen Ungewöhnliches passiert und womöglich gar nichts rundläuft.
Damit man der Geschichte glauben will, sollte das Sampling-Fenster so breit wie möglich sein. Hat die Website Outages, Geschäftszyklen und kulturelle Ereignisse überstanden, gibt es aus der Erfolgsgeschichte viel zu lernen. Verdankt sich der Erfolg dagegen der glücklichen Scheibe, in der nichts Außergewöhnliches passiert ist, suchst du besser weiter.
Und noch etwas passiert, während diese Ereignisse vorbeiziehen: Das Team bewältigt die Höhen und Tiefen im Traffic, die Outages und die Security-Updates nicht nur, es sammelt dabei Erfahrung. Am Ende hat es sich in genau das atypische Team verwandelt, um das wir uns oben beim Selection Bias gesorgt haben.
Bei sonst gleichen Bedingungen ist die Erfolgsgeschichte also beeindruckender, wenn das Fenster früh liegt statt spät. Breit genug muss es trotzdem sein, sonst schlägt der Winner's Curse zu.
Worauf man sonst noch achten sollte
Es gibt weitere Warnsignale, die zur Illusion des Erfolgs beitragen. Wegen so einer Geschichte das Tooling zu wechseln, überlegt man sich besser zweimal.
Ein Signal ist, wenn der Fokus auf neue Metriken erst mit der Änderung begonnen hat. Das ist die Geschichte "wir haben angefangen, Metriken zu erheben". Im Idealfall hätten sie ihre Schlüsselmetriken schon gemessen, bevor sie die Änderung angegangen sind. Sonst stellt sich die Frage nach dem Hawthorne-Effekt, und es fehlt die Baseline, an der sich die Verbesserung messen ließe.
Ein weiteres Signal ist, wenn nicht ausbuchstabiert wird, wie die Star-Komponente mit dem übrigen Tech Stack zusammenhängt. Die anderen Komponenten waren natürlich da, und natürlich haben sie das Ergebnis beeinflusst. Vielleicht hat erst die Art, wie sie den Edge Cache konfiguriert haben, Datenbank X glänzen lassen. Kein Edge Cache, kein Glanz.
Ein drittes Signal sind Verbesserungen ohne Vergleichsfall. Wenn das "resultierende System mehr Y war", dann wollen wir wissen: verglichen womit? Welches System hatte das weniger Y, und war es überhaupt vergleichbar? Competitive Prototyping oder Adversarial Testing würden so eine Behauptung untermauern.
Und zuletzt: Achte auf die regulatorischen Rahmenbedingungen. Zwischen den Ländern gibt es erhebliche Unterschiede bei Datenschutz, Privatsphäre, Finanzregulierung und Arbeitnehmerrechten. Datenschutz wegzulassen macht Software schneller und billiger, Datenvorschriften umzusetzen kostet Ressourcen. USA und EU bei DSGVO-Themen zu vergleichen ist ein Vergleich von Äpfeln mit Birnen.
Ausblick
Alle Autoren wollen die Aufmerksamkeit ihres Publikums. Die Frage ist, wie man die unterscheidet, die etwas erklären wollen, von denen, die Blicke zu Geld machen. Etwas Neues oder Nützliches zu lernen ist ein fairer Tausch dafür, dass jemand die Werbeeinnahmen einsteckt. Aufgehen muss die Geschichte trotzdem, und deshalb lese ich mit kritischem Blick.
In diesem Beitrag ging es darum, wie man brauchbare Informationen sammelt, indem man genug Beispiele für eine Technologie, eine Programmiersprache, einen Algorithmus oder eine Library zusammenbekommt.
Dazu kamen die illusorischen Erfolgsgeschichten, die sich großartig lesen und deinem Team trotzdem nicht helfen: Selection Bias, Regression zur Mitte als Coach's Fallacy oder Winner's Curse, und das zu klein bemessene Sampling-Fenster. Sie locken wie die Fata Morgana in der Wüste und lassen dich stranden.
Dazu die konkreten Warnsignale: wechselnde Metriken, vage Beschreibungen, Verbesserungen ohne ordentlichen Vergleichsfall. Jedes davon kann, wie die regulatorischen Rahmenbedingungen, verhindern, dass bei dir funktioniert, was bei ihnen funktioniert hat.
Manchen ist das vielleicht zu theoretisch. Bleibt dran: In Teil zwei geht es um das Problem des nützlichen Scheiterns, und in Teil drei schauen wir uns Fallstudien an. Die versprochene Analyse des Survivor Bias bin ich euch auch noch schuldig.
