TheWhiteCode

Die Einstellungsseite hatte 41 Schalter. Ich weiß das, weil ich sie eines Abends gezählt habe, während ich versuchte herauszufinden, warum ein Nutzer „Benachrichtigungen“ nicht ausschalten konnte. Der Schalter hieß „Benachrichtigungen (Beta)“ und steuerte etwas anderes als der Schalter darüber, der auch „Benachrichtigungen“ hieß. Beide waren vor drei Jahren eingebaut worden, von Menschen, die nicht mehr im Team waren.

So beginnt ein Feature-Friedhof: nicht mit einer Entscheidung, sondern mit einer Schicht. Jede Schicht war einmal sinnvoll. Zusammen ergeben sie eine Oberfläche, die niemand mehr versteht – und die trotzdem bei jeder Änderung mitgepflegt werden muss.

Wie ein Feature stirbt, ohne dass es jemand merkt

Ein Feature wird nicht abgeschaltet. Es verliert seine Nutzer. Erst sind es wenige, dann sind es die, die es nie gebraucht haben, und irgendwann ist die Zahl so klein, dass sie in keinem Dashboard mehr auffällt. Das Feature läuft weiter, weil niemand einen Grund hat, es zu entfernen – und weil das Entfernen Arbeit ist, die niemand sieht.

Der Preis zeigt sich an drei Stellen. Jede Änderung am Datenmodell muss es berücksichtigen. Jeder neue Entwickler muss es verstehen, um es nicht versehentlich zu brechen. Und jede Migration muss es mitnehmen, auch wenn es seit zwei Jahren keine Zeile geschrieben hat. Das ist keine aktive Kostenstelle, sondern eine passive: Sie erscheint nie als Rechnung, nur als Langsamkeit.

Dazu kommt der Support. Ein Feature, das kaum jemand nutzt, wird trotzdem von denen genutzt, die es nutzen – und die melden sich, wenn es klemmt. Zwei der elf gestrichenen Features hatten zusammen mehr Tickets erzeugt als das Kernprodukt, weil ihre Randfälle niemand mehr kannte. Das ist der Punkt, an dem ein Feature nicht mehr neutral ist, sondern aktiv Arbeit erzeugt, ohne Wert zu liefern.

Die Liste

Wir haben im Herbst angefangen, Nutzung zu messen, und nach acht Wochen eine Liste gebaut. Die Kriterien waren bewusst grob: weniger als ein Prozent der aktiven Konten in acht Wochen, kein zahlender Kunde darunter, kein vertraglicher Zwang. Danach haben wir geschätzt, was die Wartung kostet – nicht in Euro, sondern in „Berührungspunkten“: Stellen im Code, die bei einer Änderung angepasst werden müssen. Die Tabelle unten ist ein Ausschnitt der Liste, nicht die ganze.

Die API v1 ist der interessante Fall. 2,1 Prozent klingt nach wenig, aber darunter waren zwei Kunden mit langen Verträgen. Also keine sofortige Abschaltung, sondern eine Frist, eine Migration und ein Dokument, das den Unterschied zwischen „abgekündigt“ und „abgeschaltet“ erklärt.

Löschen ist teurer als Bauen

Das Entfernen eines Features ist aufwendiger als das Einbauen, weil es drei Parteien gibt: den Code, die Daten und die Menschen. Der Code ist der einfachste Teil. Die Daten bleiben, weil niemand eine Spalte löscht, in der noch etwas stehen könnte. Und die Menschen haben Erinnerungen: „Das brauchen wir für den Kunden X“, sagt jemand, und dann stellt sich heraus, dass Kunde X seit einem Jahr nicht mehr existiert.

Deshalb haben wir eine Regel eingeführt, die uns am Anfang schwerfiel: Wer ein Feature behalten will, nennt einen Nutzer und einen Grund. Nicht eine Vermutung, nicht eine Möglichkeit, sondern ein Konto und einen Satz. Diese Regel hat mehr Features beendet als jede Metrik, weil sie die Diskussion von „könnte sein“ zu „wer genau“ verschiebt.

Bei den Daten haben wir uns für eine andere Lösung entschieden als beim Code. Wir löschen nichts sofort, sondern frieren ein: Die Tabellen bleiben lesbar, aber schreibgeschützt, und die Oberfläche verschwindet. Das klingt nach einem Kompromiss und ist einer – aber ein ehrlicher. Er kostet wenig, er lässt sich in zwei Jahren rückgängig machen, und er zwingt niemanden, eine Migration zu versprechen, die er nicht halten kann.

Ein Prozess, der nicht wehtut

Der Prozess ist unspektakulär. Erstens: Jedes Feature bekommt beim Bau einen Eigentümer und ein Datum, an dem es überprüft wird. Zweitens: Nutzung wird gemessen, bevor jemand nach ihr fragt. Drittens: Abschaltungen laufen über eine Frist von mindestens einem Quartal, mit Ankündigung und einem Export für die Betroffenen. Viertens: Es gibt ein Dokument, in dem steht, was wann verschwunden ist und warum.

Der vierte Punkt ist der wichtigste und der, den wir zuerst weggelassen haben. Ohne dieses Dokument taucht dieselbe Idee zwei Jahre später wieder auf, diesmal von jemandem, der die erste Runde nicht miterlebt hat. Ein Feature-Friedhof ist kein Archiv aus Sentimentalität, sondern eine Sammlung von Entscheidungen, die verhindert, dass man sie ein zweites Mal teuer trifft.

Fazit

Ungenutzte Features kosten nichts, bis sie alles kosten: Aufmerksamkeit, Migrationszeit, Verständnis. Die elf, die wir gestrichen haben, haben 34 Berührungspunkte freigegeben, und das Team hat zum ersten Mal seit Jahren wieder das Gefühl, die Oberfläche zu überblicken. Das ist kein spektakuläres Ergebnis. Es ist ein leises, und leise Ergebnisse halten länger.

Welches Feature in deinem Produkt würdest du heute streichen, wenn du einen Nutzer und einen Grund nennen müsstest – und fällt dir der Nutzer schwerer als der Grund?