Future Proof Tech Briefing · September 2026
Was ich weggeworfen habe
Drei Wochen nach „Die Zielgruppe bin ich“: Ein Teil der App, über die ich geschrieben habe, existiert nicht mehr. Das ist keine Panne, sondern die eigentliche Nachricht.
Geri, zwei Generationen. Links gelötet, rechts gekauft. Das Funkprotokoll ist dasselbe geblieben.
Am 13. September habe ich die Yazio-Anbindung aus IDUN gelöscht. Ersatzlos. Monate Arbeit, ein sauberer Import, ein laufender Cron-Job, und dann ein Commit, der das alles aus dem Projekt nimmt. An ihre Stelle ist ein eigenes Ernährungsmodul getreten: Barcode-Scan, offline verfügbare Nährwertdatenbank, Import der eigenen Historie. Vier Tage Arbeit.
Das war nicht das Einzige. Rund 95 Commits und 9.300 Zeilen Swift in drei Wochen, und ein erheblicher Teil davon hat etwas ersetzt, das vorher schon funktioniert hat.
Gut getestet und trotzdem falsch
Im letzten Teil habe ich geschrieben, dass die Werkzeuge die Umsetzungskosten senken, nicht die Anforderung an das Urteilsvermögen. Drei Wochen später habe ich den Beleg, und er geht gegen mich.
Die Sensoren an meinen Handgelenken messen, wie stark die Bewegungsgeschwindigkeit innerhalb eines Satzes abfällt. Bei Kniebeugen oder Bankdrücken funktioniert das sauber. Bei Flys und Seitheben nicht. Aufgefallen ist es nicht im Code, sondern im Studio, weil die Werte nicht zu dem passten, was ich gespürt habe. Fünfzehn aufgezeichnete Sätze später war klar: Bei Drehbewegungen ist die Geschwindigkeit des Handgelenks kein brauchbares Maß für die Last. Das Modell war dort schlicht falsch.
Es stand nicht in den Tests. Tests prüfen, ob der Code das tut, was ich wollte. Sie prüfen nicht, ob ich das Richtige wollte.
Die neue Auswertung über die Winkelgeschwindigkeit ist besser als alles, was ich im August hätte planen können. Nicht, weil ich schlauer geworden bin, sondern weil die verworfene Fassung die Daten geliefert hat, an denen der Fehler sichtbar wurde.
Die Entscheidung, die sich erst später rechnet
Geri und Freki, die beiden Sensoren aus dem letzten Teil, waren selbst gelötet. Ende August habe ich sie durch fertige Hardware ersetzt. Auf dem Papier ist das die teurere Variante.
Auf dem Papier. Rechnet man die Stunden dazu, die das Löten, Testen und Nachbessern gekostet hat, kippt der Vergleich. Und die fertigen Module bringen Dinge mit, die ich beim Kauf noch gar nicht brauchte: ein Display, eine Tonausgabe, ein Mikrofon. Aus dem Display wurde inzwischen ein Rep-Zähler mit Tempoband am Handgelenk. Aus der Tonausgabe ein Taktgeber für den Satz. Beides war beim Kauf keine Anforderung, sondern nur eine offene Tür.
Genau das war die strategische Entscheidung: nicht die billigste Lösung für das heutige Problem, sondern die, die morgen mehr zulässt. Das Funkprotokoll ist übrigens unverändert geblieben. Deshalb hat die App den Wechsel der kompletten Hardware-Generation ohne Umbau überstanden.
Was als Nächstes auf dem Prüfstand steht
Die zweite Messachse kommt von der Kamera des iPads. Seit dieser Woche erfasst sie nicht mehr eine flache Silhouette, sondern siebzehn Gelenkpunkte im Raum, skaliert über meine Körpergröße aus dem Profil. Daraus entstehen pro Satz der Bewegungsumfang je Gelenk, die Abweichung zwischen linker und rechter Seite und die Bahn, die das Handgelenk über den Satz beschreibt. Kein Bild verlässt dabei das Gerät, in die Auswertung gehen ausschließlich Zahlen.
Damit habe ich zwei unabhängige Messungen derselben Wiederholung. Die Sensoren am Handgelenk liefern die Last, die Kamera liefert die Ausführung. Erst zusammen ergeben sie eine Aussage darüber, ob ein Satz schwer war oder nur schlecht.
Ehrlicherweise: Das ist Stand heute Theorie. Die 3D-Auswertung habe ich gebaut und getestet, aber noch nicht in einem einzigen richtigen Training gegen die Wirklichkeit gehalten. Das passiert in den nächsten Einheiten, und nach allem, was in diesem Text steht, ist die Wahrscheinlichkeit hoch, dass ich danach wieder etwas lösche.
Was das für die IT bedeutet
Ich mache hier im Kleinen nichts anderes als Applikationsmodernisierung. Alte Idee raus, neue rein, und die neue wird durch die Erkenntnis der alten besser. Der Unterschied zum Unternehmensalltag ist nicht die Technik, sondern die Erlaubnis.
In der Enterprise-IT ist der Irrtum das teuerste Ereignis überhaupt. Nicht, weil die Korrektur aufwendig wäre, sondern weil sie sichtbar ist: eine abgeschriebene Investition, eine Erklärung im Lenkungskreis, jemand, der die Entscheidung verantwortet hat. Also wird nicht verworfen, sondern ergänzt, gekapselt und weitergeschleppt. Genau daraus wächst das DigitalWasteland. Nicht aus schlechten Entscheidungen, sondern aus guten, die niemand zurücknehmen durfte, als sich die Lage änderte.
Drei Dinge würde ich deshalb aus diesen drei Wochen mitnehmen.
Alte Zöpfe abschneiden ist kein Scheitern. Eine Komponente, die durch eine bessere ersetzt wird, war keine Fehlinvestition. Sie war die Voraussetzung dafür, die bessere überhaupt erkennen zu können.
Der Proof of Concept ist ein Erkenntnisinstrument, kein Abnahmeverfahren. Sein Wert liegt nicht darin, eine Entscheidung zu bestätigen, die längst gefallen ist, sondern darin, herauszufinden, was strategisch wirklich zählt. Fünfzehn eigene Sätze haben bei mir mehr geklärt als jede Voranalyse.
Manche Investitionen rechnen sich erst später, und das ist in Ordnung. Saubere Schnittstellen, entkoppelte Schichten, portable Formate kosten heute mehr und zahlen sich erst in dem Moment aus, in dem etwas ausgetauscht werden muss. Mein unverändertes Funkprotokoll hat einen kompletten Hardware-Wechsel zu einer Nebensache gemacht. In größerem Maßstab heißt genau das Wechselfähigkeit, und sie ist der eigentliche Ertrag von Modernisierung.
Die Werkzeuge, über die alle reden, senken die Kosten des Bauens. Wer die Kosten des Verwerfens lässt, wo sie sind, kauft sich nur die Fähigkeit, sein Wasteland schneller zu vergrößern.
Die Kehrseite
Im letzten Teil stand, dass ohne festen Scope nichts von selbst aufhört. Drei Wochen später kann ich sagen, welcher Punkt wirklich beißt, und es ist nicht der erwartete. Der Scope hält sich, weil jedes ersetzte Modul auch eines ist, das nicht mehr gepflegt werden muss. Gewachsen ist die Prüfarbeit. Bauen ist billig geworden. Beurteilen nicht.
Und das Repo?
Weiter privat. Ein erheblicher Teil des Codes, den ich im August veröffentlicht hätte, existiert nicht mehr, und Veröffentlichen ist unumkehrbar, dieses Projekt ist es ausdrücklich nicht.
Was es gibt, ist der kleinere Weg aus den Kommentaren zur letzten Ausgabe: Ich suche eine Handvoll Contributors, die ich persönlich kenne, zum Mitarbeiten oder als Basis für eine eigene App. Ein Kommentar auf LinkedIn merkte an, dass diese Ausgabe anders als die RAMmageddon-Teile auch für private Nutzer interessant sei. Genau da liegt der Punkt. Der Code muss nicht öffentlich sein, damit er weitergegeben werden kann.
Beim letzten Mal habe ich gefragt, welches Tool ihr euch bauen würdet, wenn der Aufwand keine Rolle mehr spielt. Die beste Antwort kam aus den LinkedIn-Kommentaren, und sie war keine hypothetische: Ein Follower hat sich die eigene Schritt-App gebaut, um kein Abo mehr dafür zu bezahlen, dass jemand die eigenen Schritte zählt und die eigenen Herzdaten auswertet.
Heute die unbequemere Frage hinterher: Wann habt ihr zuletzt etwas gelöscht, das funktioniert hat?
Jens Klasen schreibt im Future Proof Tech Briefing über den Umbruch in der Enterprise-IT. Alle bisherigen Teile findet ihr in meinem Newsletter und auf klasen.ai.