Vier Jahre Yurna

Am 24. Februar 2020 habe ich das Repository angelegt. Vier Jahre später ist ein guter Zeitpunkt, einmal nicht über einzelne Umbauten zu schreiben, sondern über das Ganze.

Was daraus geworden ist

Aus fünf Befehlen in einem Ordner sind drei Anwendungen geworden, die sich eine Datenbank teilen: der Bot selbst, ein Web-Dashboard und eine Verwaltungsschnittstelle. Dazu geteilte Pakete für Datenzugriff, Übersetzungen, Konfiguration und Hilfsfunktionen.

Die Zahlen, wenn man sie mag: gut hundert Befehle in elf Kategorien, zwei Sprachen, ein Datenmodell mit dreistelliger Anzahl an Tabellen, drei Prozesse im Betrieb.

Die Zahl, die mir mehr sagt: Das Projekt läuft seit vier Jahren durchgehend, mit einem einzigen längeren Ausfall — den dreien Tagen im September 2020, als niemand gemerkt hat, dass der Bot weg war.

Die Entscheidungen, die sich gehalten haben

Eine Datei pro Befehl, Logik getrennt vom Aufrufweg. Getroffen im März 2020 aus reiner Unbequemlichkeit. Sie hat die Slash-Umstellung überlebt, die Umstellung auf Interaktionskomponenten, und sie trägt bis heute.

Alles, was länger dauert als ein Prozessleben, kommt in die Datenbank. Gelernt an Verlosungen, die einen Neustart nicht überlebten. Gilt inzwischen für Zeitgeber, Abklingzeiten, Sitzungen und Aufgaben.

Fail-closed bei allem, was mit Rechten zu tun hat. Im Zweifel verweigern. Diese Haltung hat mir mehrfach Ärger erspart und einmal einen Fehler beschert, über den sich jemand beschwert hat — was mir lieber ist als andersherum.

Optionale statt vorausgesetzter Zusatzdienste. Alles, was nur beschleunigt, darf keine Installationsvoraussetzung sein.

Struktur dort, wo Reibung ist. Nicht auf Vorrat, sondern dort, wo mich beim Arbeiten regelmäßig etwas stört. Das ist der beste Auslöser für Umbauten, den ich kenne.

Die Entscheidungen, die ich zurückgenommen habe

Postgres. Für diese Last überdimensioniert, seit anderthalb Jahren erkannt, bisher nicht geändert. Steht dieses Jahr an.

Directus. Ein halbes Jahr Content-System, dann wieder raus.

Ein eigener Musikbefehl. Freiwillig entfernt.

Achtzehn Befehle. Nach Messung entfernt, nachdem sie in drei Monaten kein einziges Mal aufgerufen worden waren.

Eine Regelsprache für Ticket-Automatik. Gebaut für unendliche Möglichkeiten, benutzt werden drei Muster.

Was diese Liste zeigt: Die meisten Rücknahmen betreffen Dinge, die ich gebaut habe, weil sie möglich oder üblich waren — nicht, weil ein konkretes Problem danach verlangt hat.

Was ich unterschätzt habe

Wie viel Zeit Betrieb kostet. Ich habe vier Jahre lang unterschätzt, dass ein laufendes System dauerhaft Aufmerksamkeit will, unabhängig davon, ob man daran entwickelt. Updates, Migrationen, Sicherheitsmeldungen, Support, Ausfälle.

Wie schwer es ist, Dinge zu entfernen. Der technische Teil ist trivial. Der Rest — ankündigen, begründen, Rückweg offenhalten, Daten aufbewahren — ist ein Vielfaches.

Wie wichtig Sichtbarkeit ist. Mehrere meiner Features wurden nicht benutzt, weil niemand wusste, dass es sie gibt. Eine Übersichtsseite hat mehr Wirkung gehabt als drei neue Funktionen.

Was ich überschätzt habe

Die Bedeutung von Funktionsumfang. „Über 150 Befehle" war jahrelang mein Werbeargument. Es beantwortet keine Frage, die ein Nutzer hat.

Die Bedeutung von neuen Techniken. Ich habe zweimal größere Umbauten begonnen, weil etwas neu und interessant war. Einmal habe ich abgebrochen, einmal durchgezogen. In beiden Fällen war der Nutzen kleiner als erwartet.

Was ich jemandem raten würde, der heute anfängt

Fang bei etwas an, das du selbst benutzt. Der einzige Grund, warum dieses Projekt vier Jahre gehalten hat, ist, dass ich es täglich sehe.

Mach den Betrieb früh ordentlich. Neustart bei Absturz, ein Lebenszeichen, eine Sicherung, die geprüft wird. Das sind drei Abende, die alles danach entspannen.

Miss, was benutzt wird. Vom ersten Tag an, wenigstens grob. Ohne das baust du nach Gefühl, und dein Gefühl ist nicht repräsentativ.

Rechne mit fünf Jahren, nicht mit fünf Monaten. Alles, was du in Monat drei aus Bequemlichkeit entscheidest, begleitet dich in Jahr vier noch.

Was ich über die Lebensdauer von Code gelernt habe

Vier Jahre sind lang genug, um zu sehen, welche Teile überleben und welche nicht. Das Muster ist deutlicher, als ich erwartet hätte.

Am längsten überlebt: alles, was eine Sache tut. Die Levelformel, die Berechtigungsprüfung, die Formatierung von Zeitspannen. Solche Funktionen sind heute weitgehend unverändert.

Am kürzesten überlebt: alles, was Aufrufwege betrifft. Wie ein Befehl entgegengenommen wird, wie geantwortet wird, wie Ereignisse verarbeitet werden — dieser Bereich wurde dreimal umgebaut.

Dazwischen: alles, was Zustand verwaltet. Das Datenmodell hat sich weiterentwickelt, aber die Grundstruktur — Server, Mitglied, Einstellung — steht seit dem ersten Entwurf.

Daraus folgt eine ziemlich klare Empfehlung: Trenne die Sache von ihrem Aufrufweg. Das ist keine theoretische Sauberkeit, sondern die Beobachtung, dass diese beiden Teile völlig unterschiedliche Lebensdauern haben.

Der Aufwand, den ich rückblickend am meisten unterschätzt habe

Nicht Entwicklung. Nicht Betrieb. Migrationen.

In vier Jahren: ein Datenbankwechsel, eine Bibliotheks-Hauptversion, eine Umstellung des Aufrufmodells, ein Zusammenführen von drei Repositories, eine Sprachumstellung, ein Serverumzug.

Jede davon war mehrere Wochen Arbeit, und keine hat eine einzige neue Funktion gebracht. Zusammen dürften sie ein gutes Drittel meiner gesamten Zeit ausgemacht haben.

Das ist keine Klage. Es ist die realistische Erwartung an ein Projekt, das über Jahre läuft: Ein erheblicher Teil der Arbeit besteht darin, das Bestehende in der Gegenwart zu halten. Wer damit nicht rechnet, plant Funktionen ein, für die keine Zeit da ist, und wundert sich, warum nichts vorangeht.

Was ich in vier Jahren nicht gelöst habe

Zu einem ehrlichen Rückblick gehört, was offen geblieben ist — und bei mir sind es drei Dinge, die sich seit Jahren halten.

Die Frage nach Geld. Struktur steht, Entscheidung nicht. Der Grund ist keine technische Hürde, sondern die Frage, wie viel Verpflichtung ich neben allem anderen tragen will.

Die vollständigen Fehlerobjekte in Protokollen. Bekannt, gezählt, nicht behoben. Rund neunzig Stellen, und jede einzeln durchzusehen ist eine Arbeit, für die es nie einen Anlass gibt.

Die Dokumentation über Entscheidungen. Es gibt Anleitungen für Nutzer und Notizen für mich. Was fehlt, ist die Ebene dazwischen: warum etwas so gebaut ist.

Diese drei haben gemeinsam, dass sie keinen Auslöser haben. Nichts geht kaputt, niemand beschwert sich, kein Termin drängt.

Das ist der Grund, warum sie so lange überleben — und der Grund, warum ich sie hier hinschreibe: Ein aufgeschriebener offener Punkt ist schwerer zu ignorieren als ein gedachter.

Und weiter?

Für dieses Jahr steht der größte strukturelle Umbau seit dem Monorepo an: Die Verwaltungsschnittstelle soll unabhängig vom Bot laufen, damit ich auch dann etwas nachsehen und steuern kann, wenn eine der Anwendungen liegt.

Das ist keine Funktion, die jemand sieht. Es ist die Art von Arbeit, die diesem Projekt in den letzten Jahren am meisten gebracht hat.