Entwicklungstagebuch, Teil 2 · 6. August 2026
„Das ist die Ursache.“
Diesen Satz habe ich in zwei Tagen dreimal gehört. Zweimal war er falsch.
Der Abend, an dem die Karte grau blieb
Mittwochnachmittag. Die Törnkarte zeigte die gefahrene Strecke als blaue Linie, die Zoomknöpfe gingen, unten stand ordentlich „© OpenStreetMap-Mitwirkende“.
Nur die Karte selbst fehlte. Graue Fläche, nichts darauf.
Die erste Erklärung kam nach zwei Minuten und klang überzeugend: eine Sicherheitsregel des Servers, die das Laden der Kartenkacheln verhindere. Ich bekam eine korrigierte Datei, lud sie hoch. Grau.
Die zweite kam nach zehn Minuten und klang ebenfalls überzeugend: eine zweite Sicherheitsregel aus einem übergeordneten Verzeichnis, die die erste überstimme. Neue Datei. Hochgeladen. Grau.
Die dritte betraf einen Zwischenspeicher, der am selben Nachmittag eingebaut worden war. Immerhin ein Fehler auf der richtigen Seite. Behoben hat es nichts.
Irgendwann habe ich geschrieben:
Langsam komme ich mir verarscht vor.
Das war unhöflich. Es war auch berechtigt, und der Grund war nicht der Fehler.
Der Grund war, dass nicht gemacht wurde, was ich wollte — und dass jedes Mal etwas anderes herauskam. Ich hatte nicht um eine Erklärung gebeten. Ich hatte um eine Ursache gebeten. Bekommen habe ich drei Stunden lang plausible Geschichten, jede davon anders als die vorige, jede mit einer Datei zum Hochladen dran.
Wer dreimal hintereinander ein anderes Ergebnis bekommt, hat nicht ein schwieriges Problem. Er hat ein Verfahren, das rät.
Dreißig Sekunden
Also haben wir ein Prüfwerkzeug gebaut. Es fordert dieselbe Kachel auf vier verschiedene Arten an und schreibt auf, welche durchkommt.
Es lieferte die Antwort in dreißig Sekunden.
Die Ursache stand die ganze Zeit im Fehlerbericht der App. Sie war dreimal gesehen und dreimal als Nebenwirkung des eigenen Tests abgetan worden.
Kartenkacheln sind normalerweise Bildanfragen. Sobald aber ein Hintergrundprozess dazwischentritt, werden sie technisch zu etwas anderem, und die Sicherheitsregel behandelt sie nach anderen Maßstäben. Eine Zeile in einer Serverdatei. Ein halber Tag.
Seither steht das als Kommentar im Quelltext, damit es nicht verlorengeht:
Eine Meldung wegzuerklären, statt sie zu prüfen, führt dazu, dass man danach an der falschen Stelle weitersucht.
Zwei Sätze, die keine Maschine weiß
Am nächsten Vormittag ging es um das Logbuch. Eingebaut war eine Regel, die seemännisch klang: Wer in einem Hafen angekommen ist, legt dort auch wieder ab. Der Zielhafen des letzten Eintrags wird also zum Ausgangshafen des nächsten.
Ich habe geschrieben:
Nein, es ist nicht seemännisch richtig. Wenn ich mich auf einem Törn von Rostock nach Vitte befinde, mache ich mindestens stündlich einen Logbucheintrag und will nicht ständig den Ausgangshafen ändern. Der ist und bleibt Rostock, bis ich in Vitte festgemacht habe.
Zwei Sätze, und die Regel war widerlegt. Von und Nach gehören nicht zum einzelnen Eintrag, sondern zur Etappe. Zwischen Ablegen und Festmachen bleiben beide gleich, egal wie viele Stundeneinträge dazwischenliegen.
Das ist kein Programmierfehler. Es ist ein Wissensfehler — und keine Textvorhersage der Welt schließt ihn, weil die Antwort nur jemand kennt, der es getan hat.
Meine nächste Frage war, ob es dafür einen eigenen Knopf braucht. Die Antwort war nein, und sie war gut: Die Etappe steht längst im Logbuch. „Ablegen“ eröffnet sie, „Festgemacht“ schließt sie. Man muss sie nur lesen.
Nebenbei entstand dabei etwas, das niemand geplant hatte — ein Knopf für den Stundeneintrag und die Möglichkeit, ihn automatisch setzen zu lassen. Mit dem ausdrücklichen Hinweis, dass das nur funktioniert, solange die App offen und der Bildschirm an ist. Ein Browser darf im Hintergrund nichts tun. Das ist eine Einschränkung, und sie steht dort, wo man sie liest, nicht im Kleingedruckten.
Der Satz, der geblieben ist
Am Nachmittag hakte es an einer Auswahlliste. Ich bekam eine Erklärung, eine Korrektur, eine zweite Erklärung, eine zweite Korrektur.
Beim vierten Anlauf habe ich geschrieben:
Wieder ändert sich der Reiter nicht nach Änderung, nicht raten!
Daraufhin wurde eine Messanzeige eingebaut, die auf den Bildschirm schreibt, was in dem Feld tatsächlich steht. Danach war es eine Sache von Minuten: ein überflüssiges Ereignis, ausgelöst an einer Stelle, an der es nichts zu melden gab — und dabei die eben getroffene Auswahl wieder verworfen.
Dasselbe Muster wie am Vortag mit der Karte. Vier Anläufe raten, dreißig Sekunden messen.
Die Messanzeige ist inzwischen wieder ausgebaut. Geblieben sind drei Werkzeuge, die es vorher nicht gab:
- eine Übersicht, welche Programmteile tatsächlich geladen sind,
- Fehlermeldungen, die den Dateinamen mitliefern statt nur den Wortlaut,
- eine Prüfung der externen Dienste, die zwischen „die App funktioniert“ und „das Wetter kommt an“ unterscheidet.
Alle drei sind entstanden, weil vorher zu lange im Dunkeln gesucht wurde.
Was sonst noch passiert ist
In der Aufzählung sieht es beeindruckend aus: eine zusammengeführte Wetteransicht statt zweier verwirrend ähnlicher, ein eigener Hafenbestand für neunzehn Reviere von der Nordsee bis Estland, Import und Export in fünf Formaten, ein neu geordnetes Eingabefenster, einundzwanzig neue Symbole, Kartenkacheln, die auch ohne Netz funktionieren.
So war es aber nicht. Es war ein Wechsel aus Bauen, Prüfen, Verwerfen und Nachbessern — und die Hälfte der Zeit ging für die drei Stellen drauf, an denen geraten statt gemessen wurde.
Was ich mitnehme
Die beiden Tage haben mir beigebracht, worauf ich seitdem bestehe, und es ist kein technischer Satz:
Eine Erklärung ist keine Ursache. Und wer bei jedem Anlauf ein anderes Ergebnis liefert, hat noch nicht angefangen zu messen.
Das gilt für die Maschine. Es gilt aber genauso für mich, wenn ich am Boot stehe und meine, ich wüsste schon, woran es liegt.
Im nächsten Teil geht es um fünf Reiter, die nichts hielten — und um die Frage, was schlimmer ist: ein leeres Feld oder eine Beschriftung ohne Funktion.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.