Feature-Wildwuchs aufräumen, ohne Nutzer zu vergraulen

Nachdem die Auswertung gezeigt hatte, dass rund dreißig Befehle in drei Monaten nie aufgerufen wurden, stand die Frage im Raum, was damit passiert. Löschen ist die einfache Antwort und war nicht die richtige.

Die Einteilung

Ich habe jeden Kandidaten in eine von vier Gruppen gesteckt.

Gruppe 1: Wird nicht gefunden. Die Funktion ist sinnvoll, der Weg dorthin schlecht. Beispiel: ein Befehl zum Exportieren der eigenen Daten, den man nur kennt, wenn man die Datenschutzerklärung gelesen hat. Lösung: bessere Benennung, Verweis aus verwandten Befehlen, Erwähnung in der Hilfe.

Gruppe 2: Wird von einem einzigen Server benutzt. Kein Argument fürs Löschen, aber eins gegen weitere Pflege. Diese Befehle bleiben, bekommen aber bei Umbauten keine Sonderbehandlung mehr.

Gruppe 3: Machbar, aber falsch platziert. Beispiel: mehrere Bildbearbeitungsspielereien. Sie funktionieren, sie kosten Rechenzeit, und sie haben mit dem Kern des Bots nichts zu tun. Kandidaten fürs Entfernen.

Gruppe 4: Schlicht schlecht. Features, die nicht richtig funktionieren, deren Bedienung unklar ist oder die eine Idee umsetzen, die sich als Sackgasse erwiesen hat. Weg.

Von dreißig Kandidaten landeten sieben in Gruppe 1, fünf in Gruppe 2, elf in Gruppe 3 und sieben in Gruppe 4. Entfernt wurden also achtzehn.

Wie ich abgeschaltet habe

Der Ablauf, den ich mir dafür zurechtgelegt habe und den ich seitdem für jede Abschaltung benutze:

Vier Wochen vorher: ankündigen. Im Support-Server, in einer Nachricht bei Aufruf des Befehls, und in der Hilfe. Mit Datum und Begründung.

Zwei Wochen vorher: Hinweis verschärfen. Der Befehl funktioniert weiter, meldet aber deutlich, wann er verschwindet und was es stattdessen gibt, falls es etwas gibt.

Am Tag X: Befehl entfernen, Daten behalten. Die Tabellen bleiben zunächst stehen. Wenn jemand sich meldet, ist nichts unwiderruflich.

Drei Monate später: Daten entfernen, mit einer Sicherung, die noch ein Jahr aufbewahrt wird.

Das klingt übertrieben für ein Hobbyprojekt. Es hat einen praktischen Grund: Der Aufwand für den Rückweg ist beim Abschalten fast null, wenn man ihn plant — und beträchtlich, wenn man ihn improvisieren muss.

Die Reaktion, die mich überrascht hat

Ich hatte mit Widerspruch gerechnet. Gekommen ist fast nichts. Zwei Nachfragen zu einem Befehl, sonst Schweigen.

Was stattdessen kam, war unerwartet: mehrere Rückmeldungen, dass der Bot sich "aufgeräumter" anfühle. Die Befehlsliste beim Tippen war kürzer, die Hilfe übersichtlicher, die Kategorien hatten wieder erkennbare Themen.

Das hat mir eine Sache klargemacht, die ich vorher nicht auf dem Schirm hatte: Umfang ist auch für die Nutzer eine Last, nicht nur für den Entwickler. Ich hatte Features immer als Angebot gesehen — nimm, was du brauchst, ignoriere den Rest. Tatsächlich muss man den Rest aber jedes Mal überfliegen, wenn man etwas sucht.

Was das Aufräumen technisch gebracht hat

Ein paar Zahlen aus dem Vorher-Nachher, die ich nicht erwartet hatte:

• Die Startzeit des Bots sank spürbar, weil weniger Module geladen und weniger Befehle angemeldet wurden.
• Die Prüfung des gesamten Projekts lief schneller, weil weniger Code zu prüfen war.
• Drei Abhängigkeiten konnten raus, weil sie nur von entfernten Befehlen gebraucht wurden. Damit auch drei potenzielle Sicherheitsmeldungen weniger.

Der letzte Punkt ist der, den ich am meisten unterschätzt hatte. Jede Abhängigkeit ist eine dauerhafte Verpflichtung — sie will aktualisiert werden, und wenn eine Schwachstelle gemeldet wird, muss man reagieren. Für einen Befehl, den niemand benutzt, ist das ein schlechtes Geschäft.

Die Reaktionen, mit denen ich gerechnet hatte

Ich hatte mich auf Widerspruch vorbereitet und mir sogar Antworten zurechtgelegt. Gekommen ist fast nichts — und die wenigen Rückmeldungen waren aufschlussreich.

„Der Befehl war doch praktisch." Zweimal, beide zu Funktionen, die tatsächlich benutzt wurden — nur von wenigen. Beide sind geblieben, in einer schlankeren Form.

„Warum jetzt?" Die Frage, die ich unterschätzt hatte. Menschen akzeptieren Änderungen, wenn sie den Anlass verstehen. „Wir konzentrieren uns auf das, was benutzt wird" ist ein Anlass. Ein wortloses Verschwinden ist keiner.

Und einmal: „Endlich." Von jemandem, der die Befehlsliste unübersichtlich fand. Damit hatte ich überhaupt nicht gerechnet.

Was ich beim nächsten Aufräumen anders machen würde

Früher anfangen. Ich habe drei Jahre gesammelt und dann in einem Rutsch aufgeräumt. Eine kleine Runde pro Halbjahr wäre unauffälliger und weniger Arbeit gewesen.

Die Entfernung vorbereiten, bevor gebaut wird. Ein Feature, dessen Daten in eigenen Tabellen liegen und dessen Code in eigenen Dateien steht, lässt sich in Minuten entfernen. Eines, das sich in gemeinsame Strukturen eingewoben hat, kostet Tage. Diese Trennung kostet beim Bauen fast nichts — man muss nur daran denken, dass ein Feature ein Ende haben könnte.

Die Nutzungszahl von Anfang an mitschreiben. Ohne sie ist jede Entfernung eine Meinung, und Meinungen kann man diskutieren. Zahlen beenden solche Diskussionen.

Der letzte Punkt hat einen Nebeneffekt, den ich erst später bemerkt habe: Wenn man die Zahlen kennt, baut man von vornherein weniger Überflüssiges. Nicht weil man vorsichtiger wird, sondern weil man ein realistisches Bild davon bekommt, wie selten ein durchschnittliches Feature benutzt wird.

Was ich mitnehme

Software wächst von allein und schrumpft nur durch Entscheidungen. Das gilt für Features, für Abhängigkeiten, für Konfigurationsoptionen und für Datenbankfelder.

Ich habe mir deshalb angewöhnt, einmal im Jahr eine Runde zu drehen: Was wird nicht benutzt? Was habe ich zuletzt vor zwei Jahren angefasst? Welche Option hat außer mir nie jemand verstellt? Das dauert einen Nachmittag und ist die produktivste Zeit des Jahres — obwohl, oder gerade weil, dabei nichts Neues entsteht.