Entwicklungstagebuch, Teil 22 · 26. August 2026
Fünf Fragen an einem Tag, die nichts miteinander zu tun hatten. Mann über Bord. Ankeralarm auf zwei Geräten. Android. Aufbewahrungsfristen. Und ein Satz im medizinischen Katalog.
Am Abend war es dieselbe Frage: Wer darf das eigentlich entscheiden — und tut die Software so, als könnte sie es?
Der Plotter navigiert, die App schreibt mit
Angefangen hat es mit einer Funktion, die es noch nicht gab: Mann über Bord. Die Datenstruktur liegt seit Monaten im Programm — Art des Vorfalls, betroffene Person, Zustand. Es fehlte nur der Knopf.
Die naheliegende Frage war, ob eine Rückpeilung dazugehört. Also: die Richtung zurück zur Person im Wasser.
Die Antwort war nein, und die Begründung hat mir eingeleuchtet. Das macht der Kartenplotter. Der kennt Kreiselkurs, Strom und Kartenbild. Ein zweites Gerät, das eine zweite Zahl anzeigt, macht eine Rettung nicht sicherer.
Eine App, die sich im Notfall neben ein Gerät stellt, das es besser kann, ist nicht hilfreich. Sie ist im Weg.
Was bleibt, ist genau das, was der Plotter nicht tut: mitschreiben.
Dazu kam mir dann noch etwas, das vorher niemand auf dem Zettel hatte, und der Gedanke dahinter ist ganz einfach: Irgendwann muss der Notfall auch als beendet gelten. Sonst fehlt der Logbucheintrag — und an dem hängt alles. Der Törn, die Dauer, die Auswertung, das Dokument, das man aufbewahren muss. Ein Vorfall ohne Ende ist in einem Logbuch kein Vorfall, sondern eine Lücke.
Also braucht es nach einem Mann-über-Bord einen zweiten Knopf: die Person ist wieder an Bord.
Und der hat beim Bauen eine Entscheidung erzwungen, an die ich selbst nicht gedacht hatte. Nach einem MOB ist viel zu tun. Die Person ist vielleicht verletzt. Man drückt den Knopf also spät — eine Viertelstunde später, eine halbe. Stünde dann die Druckzeit im Logbuch, wäre sie falsch. Und das Logbuch ist ein Dokument, das aufbewahrt werden muss.
Die App schlägt jetzt die aktuelle Uhrzeit vor und lässt sie ändern. Die Dauer rechnet sie weiter aus dem echten Auslösezeitpunkt. Wer die Uhrzeit korrigiert, korrigiert damit nicht die Wahrheit über die Dauer.
Und es gibt ein Ende, das nicht „wieder an Bord“ heißt. Freier Text, keine Auswahlliste. Die App benennt so einen Ausgang nicht. Ohne das bliebe entweder ein Vorgang, der ewig offen steht — oder ein Logbucheintrag, der nicht stimmt, weil es der einzige Knopf war.
Zwei Geräte, eine Wache
Die zweite Frage betraf die geplante native App. Das iPad stellt den Ankeralarm, das iPhone soll nachts wecken. Was heißt dann „unabhängig voneinander“?
Ich hatte die Frage falsch herum gestellt: Über welchen Weg erreicht der Alarm das zweite Gerät?
Richtig ist: über gar keinen. Ein Gerät, das nachts weckt, muss selbst messen. Eigenes GPS, eigener Ankerpunkt, eigener Ton. Alles andere hängt an fremder Infrastruktur, und kein Zustelldienst sagt dir zu, wann eine Nachricht ankommt. Oder ob.
Wenn aber beide Geräte ohnehin selbst wachen, trägt die Verbindung zwischen ihnen nur noch zwei Hausmitteilungen: „Ankerpunkt versetzt“ und „quittiert“. Beides ist selten, bei beidem steht ein Mensch daneben, beides kann man zur Not zweimal von Hand machen.
Daran hing die Entscheidung, und der Satz dazu ist einfach:
Jeder Fehlerfall ist dann ein Fehlalarm, nie ein verpasster.
Bricht die Verbindung ab, läutet ein Gerät weiter, obwohl das andere quittiert hat. Oder es rechnet gegen einen Ankerpunkt, der nicht mehr gilt. Beides laut. Kommt das Boot in den Kreis zurück, sehen es beide selbst.
Eine Wache, die zum Fehlalarm hin ausfällt, ist lästig. Eine, die zum Schweigen hin ausfällt, ist gefährlich.
Eine Zahl statt einer Stimmung
Die dritte Frage war Android. Sie stand seit Wochen im Register als „ob überhaupt — und nach welchem Kriterium“. Das Kriterium fehlte.
Beim Nachsehen kam heraus, dass es sich gar nicht bestimmen lässt. Weder die Website noch die App enthalten irgendeine Zählung. Kein Analysewerkzeug, kein Zählpixel. Die einzige Verbindung nach draußen ist der Wetterdienst.
Das ist eine Haltung, keine Nachlässigkeit. Sie hat nur den Preis, dass ich die Frage nach dem Anteil nicht beantworten kann.
Der Ausweg braucht keinen Einbau: In den Zugriffsprotokollen des Servers steht die Gerätekennung ohnehin. Vier Wochen auswerten, Schwelle vorher festschreiben, fertig. Die Zahl steht jetzt im Anforderungspapier.
Vorher, nicht hinterher. Das ist der ganze Unterschied zwischen einem Kriterium und einer nachträglichen Begründung.
Drei Jahre, die ich nicht zusagen kann
Am Vortag hatte ich nebenbei gesagt, der Logbucheintrag sei rechtlich vorgeschrieben. Das wollte ich nicht auf einer Annahme stehen lassen, also habe ich kurz einen befreundeten Rechtsanwalt angerufen. Zwei Minuten Telefon, und die Zahl stand: drei Jahre ab dem Tag der letzten Eintragung. Das amtliche Merkblatt sagt dasselbe.
Manchmal ist die schnellste Messung ein Anruf.
Drei Jahre stehen gegen sieben Tage. Denn eine Webanwendung, die man nicht installiert hat, verliert auf iOS ihre Daten nach sieben Tagen ohne Benutzung.
Damit ist „echte lokale Datenbank“ in den Anforderungen keine Bequemlichkeit mehr, sondern das Rückgrat. Und der Grund dafür stand bis dahin nirgends. Wer eine Anforderung später abwägt, wägt sonst ohne ihren Grund ab.
Die Entscheidung, was PELARON daraus zusagt, ist gegen die große Zusage gefallen. Drei Jahre sichere ich nicht zu. Ein verlorenes, zurückgesetztes oder verkauftes Gerät kann keine Software verhindern.
Zugesagt wird stattdessen, was trägt: Es löscht nichts von selbst. Es erinnert an die Sicherung. Es gibt alles heraus, jederzeit, ohne Konto und ohne Netz. Und es sagt dir, dass die Aufbewahrung deine Sache ist — an der Stelle, an der es zählt, nicht im Kleingedruckten.
Die Frage, die den Tag beendet hat
Im medizinischen Katalog steht bei „Mann über Bord“ ein Schritt: Auch nach scheinbarer Erholung medizinisch beurteilen lassen.
Mir war aufgefallen, dass drei der vier Schritte Handgriffe während der Rettung sind und nur dieser eine echte Nachsorge. Ich habe gefragt, ob der Katalog getrennt gehört.
Die Antwort hat meine Frage umgestellt, und zwar zu Recht. Wenn jemand über Bord geht, setzt man einen Notruf ab und übergibt die Person den Seenotrettern — ob man sie selbst herausgeholt hat oder nicht. Kein Skipper traut sich zu, medizinisch zu beurteilen, ob mit dem Geretteten alles in Ordnung ist. Und eine Rechtsfrage ist es obendrein.
Der Schnitt war also ein anderer als gedacht. Nicht „während“ gegen „danach“. Sondern was du tust gegen wer entscheidet.
Der Satz im Katalog ist in der Sache richtig und in der Form falsch. Er nennt keinen Handelnden. In einer Liste, die dem Skipper vorgelegt wird, liest sich „beurteilen lassen“ wie eine Aufgabe für ihn — und die einzige Person an Bord, die sie erledigen könnte, ist er selbst.
Beim Nachgehen kam dann der eigentliche Fund. Die App enthält an keiner Stelle einen Hinweis auf funkärztliche Beratung. Null Fundstellen, über alle Dateien gemessen.
Dabei steht die Nummer, über die sie läuft, seit Monaten im Programm: Die App wählt die zuständige Seenotleitstelle nach Position aus. Und genau dort sitzt rund um die Uhr medizinisches Personal.
Der Notfallbildschirm hat seit dem Abend einen eigenen Kasten dafür. Blau, nicht rot, und unter den Notrufwegen — ärztlicher Rat ist kein Notruf, und im Ernstfall muss auf einen Blick klar bleiben, welcher Kasten zuerst gilt.
PELARON gibt keine medizinische Einschätzung ab und verlangt keine von dir. Ob jemand unverletzt ist, entscheidet nicht der Schiffsführer.
Zweimal hat ein Prüfbefehl nichts geprüft
Zum Handwerklichen. Jede Lieferung geht mit einem Prüfbefehl hinaus, der nach dem Hochladen am Server nachzählt. Zweimal hat der an diesem Tag nichts gemessen und trotzdem eine Zahl geliefert.
Am Vormittag suchte er nach einem Wort in Behelfsschreibweise — ausgeloest statt ausgelöst —, weil beim Tippen des Prüfbefehls derselbe Fehler gemacht wurde, den er finden sollte. Ergebnis: null Treffer für eine Datei, die in Ordnung war.
Am Abend suchte er nach einem ganzen Satz, den der Quelltext über zwei Zeichenketten umbricht, weil die Zeile sonst zu lang wäre. Im Browser steht der Satz vollständig da. Das Suchwerkzeug sieht ihn nicht, weil es Zeilen sieht und keine zusammengesetzten Texte.
Zwei verschiedene Ursachen, dieselbe Form: ein Prüfbefehl, der eine andere Vorstellung von der Datei hat als die Datei. Beide Male hat es der Probelauf gefunden, nicht das Nachdenken.
Und einmal hat das Hinsehen gefunden, was die Messung nicht sehen konnte
Ein dritter Fall gehört dazu, weil er die Grenze in die andere Richtung zeigt.
Eine Messung lief über alle sichtbaren Bedienelemente in allen zwanzig Ansichten und meldete: alles in Ordnung. Das Kontrollbild danach zeigte einen deaktivierten Löschen-Knopf mit weißer Schrift auf grauem Grund. Unlesbar.
Der Grund: Dieser Knopf war in keiner der zwanzig Ansichten sichtbar. Er lebt in einem Dialog.
Für die Frage, wie ein Knopf im deaktivierten Zustand aussieht, spielt Sichtbarkeit aber keine Rolle. Die Regel gilt auch für den Knopf in einem geschlossenen Dialog. Gezählt wird seitdem über alle 222 Marken statt über die 121 sichtbaren.
Was ich mitnehme
Der Satz vom Vortag hieß: eine Regel, die es gibt, ist noch keine Regel, die gilt. Heute kommt einer dazu, und der ist unbequemer, weil er nicht die Software betrifft, sondern die Haltung dahinter.
Software soll nicht so tun, als könnte sie entscheiden, was sie nicht entscheiden kann.
Nicht die Richtung zur Person im Wasser, wenn ein besseres Gerät sie kennt. Nicht die Aufbewahrung über drei Jahre, wenn ein Gerät verloren gehen kann. Nicht den Anteil einer Plattform, wenn nichts gezählt wird. Und schon gar nicht den Zustand eines Menschen.
Was sie kann, ist erstaunlich viel. Festhalten, was wann geschehen ist. Erinnern, wenn etwas offen bleibt. Sagen, wen man fragen kann.
Und den Rest ehrlich als das benennen, was er ist: die Entscheidung von jemand anderem.
← Zurück zum Entwicklungstagebuch
PELARON entsteht an Bord der Bluebaerry und am Schreibtisch in Erfurt. Fragen, Widerspruch und Fehlermeldungen sind willkommen.