Wenn das Update zum Reset wird
Ich habe kürzlich ein Software-Update in einem VW Golf 8 erlebt — und danach erst mal ziemlich irritiert im Auto gesessen. Man erwartet ja eigentlich, dass ein Update Dinge verbessert. Vielleicht ein paar Bugs weniger, vielleicht etwas mehr Stabilität. Was ich bekommen habe, war ein kompletter Neustart.
Alle Einstellungen weg. Alle Benutzerprofile gelöscht. Sitzpositionen, Spiegeleinstellungen, Radiosender, Klimaeinstellungen — alles auf Werkseinstellung. Ein digitaler Gedächtnisverlust. Und ich sitze da und fange wieder bei null an, während ich eigentlich nur losfahren wollte.
Kein Randfall, sondern ein Architekturproblem
Das ist kein kleiner Schönheitsfehler. Das ist ein strukturelles Problem. Denn an so einer Stelle geht es nicht um ein UI-Detail oder einen Randfall, sondern um den Kern der Deployment-Strategie und den Umgang mit bestehenden Daten.
Was hier sichtbar wird, ist etwas, das wir in der Softwareentwicklung eigentlich längst verstanden haben sollten: Der Zustand des Nutzers ist kein Nebenschauplatz. Er ist zentral. Wenn ein Update diesen Zustand einfach verwirft, ohne saubere Migration oder zumindest transparente Kommunikation, dann ist das kein fertiges Release.
Wir bauen für Menschen, nicht für Testumgebungen
Wir reden ständig über reproduzierbare Umgebungen, über Stabilität, über deterministisches Verhalten. Wir bauen Pipelines, wir automatisieren Deployments, wir achten darauf, dass alles jederzeit nachvollziehbar ist. Umso unverständlicher ist es, wenn genau diese Prinzipien an der Stelle aufhören, an der der Nutzer ins Spiel kommt.
Denn am Ende programmieren wir nicht für unsere Testumgebung. Wir programmieren für echte Menschen in echten Situationen. Für jemanden, der morgens ins Auto steigt und einfach los will. Nicht für jemanden, der erst einmal ein Setup-Menü durchklicken möchte, weil ein Update beschlossen hat, alles zurückzusetzen.
Migration ist kein Feature — es ist Pflicht
In der Webentwicklung ist das Thema längst Standard. Datenbank-Migrationen laufen automatisch. Konfigurationen werden versioniert. Nutzerdaten werden bei Updates migriert, nicht gelöscht. Kein seriöses Web-Framework würde ein Update ausliefern, das alle User-Einstellungen löscht. Das wäre kein Bug — das wäre ein Rücktrittsgrund.
Warum akzeptieren wir das bei Autos? Warum akzeptieren wir das bei Embedded Systems, bei IoT-Geräten, bei Smart-Home-Systemen? Nur weil die Hardware physisch ist, gelten plötzlich andere Regeln?
Wenn die Migration von Bestandsdaten nicht zuverlässig funktioniert, ist das Feature nicht fertig. Dann darf es nicht raus.
Software soll dem Menschen Arbeit abnehmen. Wenn sie stattdessen neue erzeugt, nur weil der Migrationspfad zu unbequem war, dann läuft etwas grundsätzlich falsch. Ein Update, das den Nutzer zurücksetzt, ist kein Update — es ist ein Rückschritt.