Entwicklungstagebuch, Teil 4 · 9. August 2026
Die Diagnose meldete: System betriebsbereit.
Gleichzeitig fand die Hafensuche nichts, und der Wettermodellvergleich blieb leer. Zwei Kernfunktionen ausgefallen, und die App sagte, es sei alles in Ordnung.
Warum die Anzeige nicht gelogen hat
Sie hatte recht — nur über etwas anderes, als draufstand.
Geprüft wurde ausschließlich, was im Gerät liegt: Sind die Programmteile geladen? Ist der Speicher lesbar? Läuft der Offline-Dienst? Ist das Logbuch unbeschädigt?
Alles davon war in Ordnung. Kein einziger Onlinedienst wurde angefasst.
Das ist verständlich, wenn man weiß, wie so eine Prüfung entsteht. Man baut zuerst, was leicht messbar ist. Ob eine Datei geladen wurde, weiß das Gerät sofort. Ob ein fremder Server antwortet, dauert Sekunden und kann aus zehn Gründen scheitern, die mit der eigenen App nichts zu tun haben.
Also bleibt es beim Naheliegenden — und die Überschrift wächst trotzdem mit.
Eine Anzeige, die „betriebsbereit“ sagt, während zwei Kernfunktionen nicht arbeiten, kostet mehr Vertrauen, als sie stiftet.
Die Lösung war nicht, mehr zu prüfen. Sie war, genauer zu benennen. Die alte Aussage heißt jetzt, was sie immer war: Die lokalen Kernfunktionen laufen. Daneben steht eine zweite Prüfung, die tatsächlich bei den Diensten anfragt — und die zwischen „die App funktioniert“ und „das Wetter kommt an“ unterscheidet.
Der Fehler, der seinen Namen verschweigt
Am selben Tag ist mir zweimal dasselbe passiert. Ein Programmteil scheiterte beim Laden und hinterließ eine Fehlermeldung — die aber nicht verriet, welche Datei betroffen war.
Also habe ich an der falschen Stelle weitergesucht. Zweimal.
Daraus entstand eine Übersicht, die schlicht auflistet, welche Programmteile sich angemeldet haben. Jedes Modul meldet sich beim Laden an; fehlt die Meldung, liegt die Datei entweder nicht auf dem Server oder ist beim Laden gescheitert.
Das ersetzt keine Fehlermeldung. Aber es beantwortet die erste Frage, und zwar in Sekunden statt in einer Stunde. Dazu die kleinere, wirksamere Änderung: Fehlermeldungen liefern jetzt den Dateinamen mit.
Dieselbe Falle, einen Tag später — von der anderen Seite
Ich wollte wissen, wie dieses Tagebuch auf pelaron.de eigentlich verlinkt ist, und habe die Seite abrufen lassen.
Das Ergebnis war eindeutig: kein Eintrag in der Navigation, keiner in der Fußzeile, von keiner Seite ein Weg hierher. Dreimal abgerufen, dreimal dasselbe.
Dann habe ich pelaron.de auf dem iPad geöffnet. Zwischen Refit und Downloads steht: Tagebuch. Seit Tagen.
Die Auflösung ist banal. Der Menüpunkt wird beim Laden der Seite eingefügt, nicht in vierzig einzelne Dateien eingetragen — eine bewusste Entscheidung gegen vierzig Gelegenheiten, es zu vergessen. Ein Abruf, der eine Seite nur herunterlädt, sieht diesen Schritt nicht. Er bekommt das Gerüst, bevor die Ergänzung passiert.
Der Abruf hatte also korrekt gemessen. Er hatte nur eine Seite gemessen, die so nie jemand zu sehen bekommt.
Ein Messwert ist nur so gut wie das Wissen darüber, was das Messgerät nicht sieht.
Die dritte Regel
Aus dem ersten Teil stammt die Arbeitsteilung: Die Maschine baut schnell, ich korrigiere. Aus dem zweiten die Regel, erst zu messen und dann zu erklären.
Diese hier ist die Fortsetzung, eine Ebene tiefer.
Es reicht nicht, zu messen. Man muss wissen, was das Instrument grundsätzlich nicht erfassen kann — sonst wird aus einer blinden Stelle im Werkzeug ein Befund über die Welt.
Das ist kein Sonderfall der Softwareentwicklung. Ein Echolot, das den Grund nicht findet, meldet keine Tiefe. Ob das heißt „hier ist es tief“ oder „der Geber sitzt falsch“, entscheidet nicht das Gerät.
Wer ein Prüfergebnis bekommt, sollte deshalb zwei Fragen stellen. Die erste ist: Stimmt das? Die zweite: Konnte das Werkzeug das überhaupt sehen?
Die zweite wird seltener gestellt und ist häufiger die wichtigere.
Beide Male hat der Test am Ende weniger als eine Minute gedauert. Hinsehen, wo vorher nur gerechnet worden war.
Nachtrag, drei Wochen später: Dieser Teil beschreibt eine Anzeige, die „betriebsbereit“ sagte, ohne etwas zu prüfen. Am 28. August habe ich eine Kachel gefunden, die seit jeher „Keine kritische Frist“ meldete — sie fragte nach Feldern, die in der ganzen App nirgends geschrieben werden. Und eine zweite, die dauerhaft „Bereit“ sagte, weil keine einzige Datei sie je beschrieben hat.
Dieselbe Gestalt, drei Wochen später, an zwei neuen Stellen. Es ist offenbar keine Kinderkrankheit.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.