Notfall. Patientendaten verschwinden einfach aus dem System.

So ungefähr begann letztens der Anruf eines alten Bekannten, mit dem ich in der Vergangenheit schon einige Embedded-Projekte erfolgreich beendet habe.

Ein neues Produkt war gerade fertig geworden und lief jetzt beim Kunden auf echten Daten. Und ab und zu verschwanden Messdaten – unwiederbringlich. Besonders ärgerlich, weil es sich um Patientendaten handelte, zum Schaden der Patienten und des klinischen Forschungsprojekts. Vom Imageschaden mal ganz abgesehen. Für dieses Projekt hatte er mit einem neuen Entwickler zusammengearbeitet, der im Ausland saß und im Vergleich sehr viel günstiger war. Dessen Reaktion auf die Probleme war für mich erst einmal unvorstellbar: „Meine Software hat keine Probleme, sie funktioniert perfekt." Kurz nach diesem Satz hatte das Projekt einen neuen Entwickler – und er reichlich Zeit, über den Unterschied zwischen „funktioniert" und „funktioniert perfekt" nachzudenken. Ich nahm den Auftrag natürlich an, denn ich konnte nur gewinnen: schnellstmöglich den Fehler finden, ihn beheben und eine neue Version für den Kunden bereitstellen.

Der Fairness halber muss ich erwähnen: Der Fehler war kaum zu greifen. Ich brauchte mehrere Tage, nur um ihn überhaupt sauber zu reproduzieren. In diesem Prozess hatte ich phasenweise viel Verständnis für den alten Entwickler, denn auch ich war ab und zu kurz davor, die Sache abzutun.

Ich baute Analysetools, um die Logdateien auszuwerten und daraus Diagramme zu generieren. Früher eine Aufgabe von Tagen – heute dank KI in einer Stunde erledigt. Dann loggte ich mich auf meinem OpenWrt-Router ein und störte die Netzwerkverbindung des Embedded-Geräts so stark, bis ich den Fehler reproduzieren konnte.

Meine Theorie bewahrheitete sich: eine Race Condition, und sie hatte mit der MQTT-Daten-Queue zu tun. Die ADC-Daten wurden nicht sauber vom ADC-Chip abgeholt und einfach in die Queue gestopft. Wenn die Netzwerkverbindung resettet wurde, verschwanden auch die Daten aus der Queue – unwiederbringlich verloren.

Weil ich meine Validierung von Anfang an aufgesetzt hatte, konnte ich den Fehler am Ende einkreisen, finden und das Projekt sauber abschließen.

Warum ich das erzähle: Code zu generieren ist längst nicht mehr der Bottleneck in einem Projekt. Aber der Unterschied von „läuft okay" zu „läuft perfekt", Abweichungen im PPM-Bereich sichtbar machen und Probleme fixen, die kaum zu erkennen sind – das ist die Arbeit eines erfahrenen Entwicklers und Software-Architekten. Der Mensch wendet den Schaden ab, nicht das Tool.

Und noch etwas: Menschen arbeiten nur dann wirklich mit dir, wenn sie dir vertrauen. Jeder macht Fehler. Der eigentliche Fehler ist, darauf zu bestehen, keine zu machen.

Und die Moral von der Geschicht: Auch wenn du denkst, du bist unersetzlich – du bist es nicht 😉