# Sechs von neun Bugs existierten nicht

Wir führten eine geplante Überarbeitung unserer Namensdatenbank durch. Der Plan umfasste neun Arbeitspunkte, jeder davon ein zu behebender Defekt. Sechs davon beschrieben Defekte, die es nicht gab, oder Arbeit, die bereits erledigt war.

Keiner der sechs entsprang einer schlechten Messung. Jeder einzelne entsprang einem Absatz in unserer eigenen Dokumentation.

Das ist der Befund, und er ist unbequemer als das übliche Eingeständnis „wir haben Fehler in unseren Daten gefunden" — eines davon haben wir bereits geschrieben, und dies ist nicht dieses. Hier geht es um die Klasse von Versagen, bei der das Ticket der Bug ist: bei der ein Betreuer, der vernünftig handelt, eine Notiz liest, ihr glaubt, Arbeit darum herum plant und erst beim Kontakt mit den Daten entdeckt, dass es nichts zu tun gab. Die Arbeit kostet trotzdem, was sie gekostet hätte. Sie bringt nur nichts hervor.

Die Anzeigetafel

Fünf davon sind Phantom-Defekte. Der letzte ist von anderer Art und wert, ihn abzutrennen: die Lücke war real, und die vorgeschlagene Behebung war der Defekt. Mehr dazu weiter unten, denn dieser ist der, den man unter Zeitdruck am ehesten falsch macht.

Der Absatz, der auflistete, was hinzugefügt worden war

Der klarste Fall, und der, der sich am weitesten verallgemeinern lässt.

Eine interne Notiz lautete, sinngemäß: „Sechs echte, häufige Nachnamen hinzugefügt, die fehlten: A (Rang 42), B (Rang 46), C (#56), D und E (#60–61), F (#66)."

Das ist ein Protokoll erledigter Arbeit. Sechs Wochen später von jemandem gelesen, der nicht dabei war, ist es von einer To-do-Liste nicht zu unterscheiden. Das Wort „fehlten" steht direkt im Satz; dass es einen Zustand beschreibt, der durch die Handlung desselben Satzes zu bestehen aufhörte, wird gänzlich vom Präteritum eines einzigen Verbs getragen.

Also wurde ein Arbeitspunkt eröffnet: diese Nachnamen fehlen in der Liste. Und der Eintrag führte die Ränge — 42, 46, 56, 60 — als stützenden Beleg an.

Diese Ränge waren korrekt. Sie waren korrekt, weil die Einträge dort waren, auf genau diesen Rängen — weshalb die Notiz sie überhaupt zitieren konnte. Der Beleg für den Defekt und der Defekt selbst waren aus demselben Absatz abgeschrieben worden. Die Prüfung der Datei dauerte unter einer Minute und lieferte alle fünf Einträge auf den Rängen 42, 46, 55, 59 und 60 zurück — passend zur Notiz bis auf die Verschiebung, die man erwartet, nachdem die Liste zwischenzeitlich vertieft worden war.

Die Lehre ist nicht „schreibt klarer". Die Notiz war klar. Die Lehre ist, dass ein Satz, der eine Änderung beschreibt, standardmäßig undatiert ist, und eine undatierte Änderung liest sich als Zustand. Added A, B, C und A, B, C are missing sind für einen Leser, der nicht weiß, wann sie geschrieben wurden, derselbe Satz.

Das Ereignis, gelesen als Zustand

Dieselbe Form, größerer Wirkungsradius.

Eine Notiz hielt fest, dass 33 archaische Nachnamen mit null lebenden Trägern aus einer Liste entfernt worden waren, da sie aus einem Text des 11. Jahrhunderts statt aus einer Bevölkerung importiert worden waren. Wahr, datiert und korrekt.

Vier Tage später besagte ein Planpunkt: entferne 33 archaische Nachnamen mit null lebenden Trägern.

Beide Sätze sind über unsere Daten wahr. Sie sind wahr über verschiedene Versionen derselben Datei, vier Tage auseinander. Und Folgendes machte es schlimmer statt besser: zwischenzeitlich war die Datei aus einem Register neu gebaut worden, sodass die aktuelle Version eine echte Teilmenge eines namensweisen Registers war, in dem jedes Gewicht einer Registerzählung entsprach. Es gab nicht bloß nichts zu löschen — es gab strukturell nichts, das gelöscht werden konnte, weil hinter jeder Zeile ein Zähler stand.

Die Messung erforderte ein einziges Skript: 2.707 Einträge, alle im Register vorhanden bei byteexaktem Vergleich, null Gewichtsabweichungen, Abdeckung 99,98 %.

Die verlockende Bereinigung ist an diesem Punkt, die alte Notiz als Fehler zu streichen. Das wäre ein zweiter Fehler. Die alte Notiz ist nicht falsch — sie beschreibt ein Ereignis akkurat, und wir haben über dieses Ereignis einen Artikel veröffentlicht, der keiner Korrektur bedarf. Was der Notiz fehlte, war ein Geltungsbereich: welche Datei, mit welchem Stand. Zwei akkurate Aussagen über zwei Versionen derselben Sache, die in zwei Dokumenten ohne Datum stehen, erscheinen als Widerspruch; und ein Widerspruch in der Dokumentation ist ein Arbeitspunkt, der darauf wartet, von der nächsten Person geschrieben zu werden, die ihn bemerkt.

Der Mechanismus, der nie aufgeschrieben wurde

Ein dritter Eintrag behauptete, eine Gewichtsspalte vermische drei inkompatible Skalen und müsse auf eine einzige abgeglichen werden.

Es hatte drei Quellen gegeben. Es gab eine Skala: irgendwann zuvor waren sie abgeglichen worden, indem alles an einen einzigen Koeffizienten angepasst wurde, und der Anpassungsschritt war nie dokumentiert worden. Den Koeffizienten aus den Daten selbst zu rekonstruieren, kostete einen Nachmittag; einmal rekonstruiert, reproduziert er 1.813 von 1.886 Gewichten exakt, auf die Einheit genau.

Dann der interessante Teil. Wir maßen, was der vorgeschlagene Abgleich tatsächlich verändert hätte:

Und die Kostenseite: jene 73 Einträge waren die einzigen, deren Werte aus einer unabhängigen Quelle stammten. Sie umzuschreiben hätte die Datei vollständig in sich stimmig und dauerhaft unüberprüfbar gemacht — die einzige Menge, an der sich der Koeffizient je hätte prüfen lassen, wäre vom Koeffizienten überschrieben worden.

Eine Änderung mit einem gemessenen Nutzen von null und einer von null verschiedenen Kosten ist nicht neutral. Sie ist eine Regression. Sie sieht nur neutral aus, weil „die Skalen normalisieren" ein Satz ist, der nach Hygiene klingt.

Die echte Lücke mit der falschen Behebung

Der sechste Eintrag ist der, der Sorgfalt verdient, denn alles an ihm war vernünftig außer der Schlussfolgerung.

Zwanzig Sprachregionen hatten Städtelisten ohne Bevölkerungsgewichte, sodass Städte gleichverteilt gezogen wurden — eine Kleinstadt so wahrscheinlich wie die Hauptstadt. Das ist ein echter Defekt, ehrlich dokumentiert, mit Quellen auf der Platte für einige der Sprachregionen. Der Eintrag besagte: lade die Gewichte, die wir haben.

Gemessen deckten die Quellen 563 von 810 Städten über 14 Sprachregionen hinweg — 69,5 %. Keine einzige Sprachregion erreichte 100 %. Die beste lag bei 90,4 % und ließ fünf Städte vermissen.

Der Instinkt sagt, 69,5 % seien besser als 0 %. Sind sie nicht, und der Grund verdient eine präzise Formulierung: eine ungewichtete Liste zieht gleichverteilt, was falsch, aber über die Einträge hinweg unverzerrt ist. Eine teilweise gewichtete Liste macht die gewichteten Einträge deterministisch wahrscheinlicher und die ungewichteten deterministisch unwahrscheinlicher — und die Einträge ohne Bevölkerungszahl sind keine zufällige Stichprobe. Es sind jene mit sperrigen Namen, umstrittenen Grenzen oder mehrdeutigen Zuordnungen. Teilweises Laden unterdrückt also systematisch genau die Einträge, die am schwersten aufzulösen waren, und es tut dies, während es präziser aussieht als zuvor.

Das korrekte Ergebnis war, nichts zu laden und die 247 Lücken als Manifest aufzuschreiben, damit der nächste Versuch von einer Liste statt von einer Wiederentdeckung ausgeht. „Irgendwelche Daten sind besser als keine" ist falsch, sobald die Fehlstellen mit dem korrelieren, was man misst — was bei Geo- und Namensdaten fast immer der Fall ist.

Warum die Ursache Dokumentation ist und nicht Daten

Sechs Einträge, sechs verschiedene Länder, sechs verschiedene Arten von Behauptung, ein gemeinsamer Ursprung: ein Satz in unseren eigenen Notizen, der wahr gewesen war, als er geschrieben wurde.

Das ist strukturell, kein lokales Versagen der Sorgfalt. Eine Messung ist von Natur aus datiert — man hat sie ausgeführt, an einem Tag, gegen eine Datei, und wenn man sie erneut ausführt, erhält man die heutige Antwort. Prosa hat nichts davon. Ein Absatz weiß nicht, wann er geschrieben wurde, weiß nicht, worauf er sich bezog, und altert nicht sichtbar. Dokumentation veraltet nicht laut. Sie veraltet still und erzeugt dann Arbeit.

Wir haben eine harte Messung der Rate. Während derselben Überarbeitung wanderte eine Zählung in unserer Dokumentation — wie viele Sprachregionen eine bestimmte Art von Datensatz führten — 7 → 9 → 10 innerhalb eines einzigen Tages, während parallele Arbeit eintraf. Neun Dokumente trugen diese Zählung an dreizehn Stellen. Und der Bericht, den wir schrieben, um alle dreizehn zu korrigieren, veraltete zwanzig Minuten nach dem Schreiben, weil zwischenzeitlich ein weiterer Job fertig wurde und die Zahl zu 10 machte.

Das ist keine Anekdote über Ironie. Es ist die Randbedingung. Sorgfalt war es, die die erste Version hervorbrachte, also kann „sei sorgfältiger" nicht das Heilmittel sein.

Das Heilmittel: eine Zahl ohne Neuberechnung ist eine Landmine

Die Regel, die wir nun anwenden, und die einzige aus dieser Übung, die den Kontakt mit einem realen Projekt übersteht:

Schreibe niemals eine Zählung in Prosa, ohne daneben zu schreiben, wie man sie neu berechnet.

Eine bloße Zahl nennt eine Tatsache über einen Moment. Eine Zahl plus Neuberechnung nennt eine Tatsache über das Jetzt. Der Unterschied kostet eine Zeile und beseitigt eine ganze Fehlerklasse — denn der nächste Leser muss nicht entscheiden, ob er der Zahl trauen soll; er kann zehn Sekunden aufwenden, um es herauszufinden.

Die zweite Regel betrifft das Tempus. Jeder Tatsachensatz in einer Projektdokumentation sollte sich, ohne umgebenden Kontext, als genau eines von diesen einordnen lassen:

Ein Satz, der sich nicht einordnen lässt, ist ein Phantom-Arbeitspunkt, der noch nicht geschrieben wurde.

Warum „zuerst prüfen" ein schwierigerer Rat ist, als er klingt

Alle stimmen zu: „prüfe die Prämisse, bevor du die Arbeit planst." Fast niemand tut es, und der Grund ist eine echte Asymmetrie und nicht Faulheit.

Ein Dokument zu lesen dauert Sekunden und erfordert nichts. Eine Prüfung auszuführen dauert Minuten, erfordert das Wissen, was auszuführen ist, und erfordert die Daten zur Hand. Die natürliche Reihenfolge lautet also: lesen, einen Plan fassen, dann während der Ausführung verifizieren. Diese Reihenfolge ist genau verkehrt herum — denn wenn die Ausführung beginnt, ist der Plan bereits aufgeschrieben, terminiert, mit Personal versehen und in einer Besprechung verteidigt worden. Verifikation während der Ausführung streicht keine Arbeit; sie entdeckt bloß, teuer, dass die Arbeit sinnlos war.

Es gibt außerdem einen spezifischen Grund, warum sich Phantom-Einträge solide anfühlen: sie sind präzise. „33 Phantom-Nachnamen" trägt eine Zahl, und Zahlen lesen sich als gemessen. Jene war gemessen — vier Tage früher, gegen eine Datei, die in dieser Form nicht mehr existierte. Genauigkeit ist kein Beleg für Aktualität, und sie ist die zuverlässigste Art, in der sich eine veraltete Behauptung als frische tarnt.

Unsere eigene Abrechnung für diese Überarbeitung: mindestens drei volle Arbeitssitzungen flossen in Einträge, die ein einminütiger Blick in die Daten geschlossen hätte. Der Scan existiert nun und ist erneut ausführbar, was das einzige dauerhafte Ergebnis ist, das irgendeine dieser Sitzungen hervorbrachte.

Die Checkliste

1. Prüfe die Prämisse gegen die Daten als erste Handlung — vor der Planung, nicht während der Ausführung. Lässt sich die Prämisse nicht günstig prüfen, ist das selbst schon der erste Befund.
2. Schreibe niemals eine Zählung ohne das Mittel, sie neu zu berechnen. Eine Zahl in unseren Notizen änderte sich an einem Tag zweimal und lebte an dreizehn Stellen.
3. Datiere jeden Tatsachensatz und lege sein Tempus fest. „X hinzugefügt" und „X fehlt" sind ohne Datum derselbe Satz.
4. Ein Protokoll dessen, was hinzugefügt wurde, ist keine Liste dessen, was fehlt. Wenn eine Notiz Einträge aufzählt, prüfe, ob sie ein Beleg oder eine Anforderung ist.
5. Trenne „der Defekt ist nicht real" von „die Behebung ist nicht korrekt". Sie kommen in derselben Form und brauchen unterschiedliche Reaktionen; die eine schließt den Eintrag, die andere ersetzt ihn.
6. Teilweise Behebungen können schlimmer sein als keine, wenn der fehlende Teil keine zufällige Stichprobe ist. Miss die Abdeckung, bevor du irgendetwas lädst, und ziehe eine ehrliche Lücke einer verzerrten Auffüllung vor.
7. Korrigiere das Dokument in derselben Sitzung wie den Phantom-Eintrag. Andernfalls bleibt der Satz, der ihn erzeugte, an Ort und Stelle und erzeugt ihn erneut — wir haben genau das zweimal geschehen sehen, mit demselben Absatz.
8. Achte auf Einseitigkeit. Jeder dieser Defekte existierte in der Dokumentation und ließ sich nie gegen die Daten reproduzieren. Ein Defekt, der stets nur auf einer Seite eines Vergleichs auftaucht, ist meist ein Diagnoseproblem, kein Datenproblem.

Was es tatsächlich kostete und was es einbrachte

Die drei echten Einträge waren echte Arbeit und wurden erledigt. Die sechs wurden durch Messung geschlossen, und ihr Schließen kostete insgesamt weniger Zeit, als die Umsetzung eines einzigen von ihnen gekostet hätte.

Das wertvollste Ergebnis der Überarbeitung war keine Änderung an den Daten. Es war das Löschen und Neudatieren der Sätze, die die falschen Einträge hervorgebracht hatten — denn jene Sätze saßen noch immer dort, noch immer wahr-als-geschrieben, noch immer bereit, dieselben sechs Einträge für die nächste Person zu erzeugen, die sie sorgfältig las und in gutem Glauben handelte.

Was die unbequeme allgemeine Form ist. Eine Datenbank verfällt langsamer als ihre Dokumentation. Die Daten werden bei jedem Build von Validatoren geprüft; die Prosa darum herum wird von niemandem geprüft, altert fortlaufend und ist das, was alle zuerst lesen.

Daten mit Stand 2026-07-21

Jede Zahl in diesem Artikel wurde am 21. Juli 2026 aus den Daten neu berechnet, nicht den hier besprochenen Notizen entnommen — was für genau diesen Artikel eine ungewöhnlich schlechte Idee gewesen wäre. Die beschriebene Überarbeitung fand vom 19. bis 21. Juli 2026 an einer Namens- und Adressdatenbank statt, die 64 Sprachregionen abdeckt.

Woher die Zahlen stammen:

• 2.707 Einträge, byteexakte Registerübereinstimmung, 99,98 % Abdeckung — neu berechnet gegen das veröffentlichte namensweise Nachnamenregister der betreffenden Sprachregion; dieses Register, seine Lizenz und seine Eigenheiten sind dokumentiert in Woher unsere Taiwan-Namensdaten stammen.
• Fünf Nachnamen auf den Rängen 42, 46, 55, 59, 60 — direkt aus der ausgelieferten Liste gelesen, 298 Einträge.
• 1.813 von 1.886 Gewichten durch einen Koeffizienten reproduziert; mittlere Rangverschiebung (Median) 0; 73 von 2.222 Einträgen betroffen — gemessen, indem der Koeffizient aus den Daten neu abgeleitet und die vorgeschlagene Änderung durchgespielt wurde, ohne sie zu schreiben.
• 60 von 60 Städtegewichten; 563 von 810 über 14 Sprachregionen hinweg; 247 Lücken — gezählt aus den ausgelieferten Städtelisten und den Offline-Quellen.
• 7 → 9 → 10 an einem Tag, an 13 Stellen über 9 Dokumente hinweg — gezählt während der Dokumentationsüberarbeitung selbst.
• Das Vornamenregister, von dem es hieß, es existiere nicht, wird von Istat veröffentlicht, dem nationalen Statistikinstitut Italiens, und deckt 1999–2024 ab.

Der Begleitartikel, der acht inhaltliche Fehler anderer Art behandelt — falsche Nenner, zirkuläre Verifikation, Zombie-Statistiken —, ist Was wir über Namensdaten falsch verstanden haben. Die allgemeine Methode zum Prüfen dieser Klasse von Behauptungen findet sich in Wie man einen Namenshäufigkeits-Datensatz auditiert.