Hauptgedanke

Ein Repository, das ein Feature Flag enthält, enthält nicht ein Verhalten, sondern zwei — und es sagt nicht, welches ausgeführt wird. Das Lesen des Codes stellt dann fest, dass beide existieren, nie, welches gilt. Fragt ein Customer Success Manager „Unter welchen Bedingungen bleibt dieser Workflow bei diesem Kunden hängen?“, steht die Antwort nicht in den Dateien: Sie liegt im Zustand des Flags in der Umgebung, in der dieser Kunde arbeitet.

Daraus ergeben sich zwei Arten zu antworten, und sie sind nicht gleich viel wert. Ohne Zugriff auf die Umgebung bleibt die Antwort bedingt: Ist das Flag aktiv, gilt dieses Verhalten, sonst ein anderes. Mit diesem Zugriff wird sie zu einer Antwort über das Produkt, so wie genau dieser Kunde es erlebt, in seiner Konfiguration, zu diesem Zeitpunkt.

Der Punkt reicht über die Mechanik der Flags hinaus. Eine Frage aus dem Support oder dem Vorvertrieb zielt fast nie auf den Code im Abstrakten; sie zielt darauf, was ein bestimmtes Kundenkonto auf dem Bildschirm sieht. Das Repository zur Quelle der Wahrheit zu erklären, schlichtet den Streit zwischen dem Code und einer veralteten Dokumentation und lässt den Abstand zwischen dem Code und einem Deployment unberührt. Die vollständige Quelle des beobachteten Verhaltens ist ein Paar: das Repository und der Zustand der Umgebung, die es ausführt.

Warum das wichtig ist

Das verhindert, die Verlagerung hin zum Code zu schnell zu lesen. „Die Wahrheit ist das, was läuft“ meint das Repository, solange man über das Produkt im Allgemeinen spricht, und hört auf, es zu meinen, sobald es um einen Kunden geht — und das ist bei den meisten Fragen der Fall, die täglich eintreffen.

Es legt auch fest, was jemand aus dem Vertrieb zusagen darf. Ein Verhalten, das im Repository steckt, ist noch kein Verhalten, das dem Interessenten zur Verfügung steht, der ihm gegenübersitzt, und der Unterschied zwischen beiden steht in einer Einstellung, nicht im Code.

Nuancen und Grenzen

Die Abhängigkeit von der Konfiguration betrifft nur einen Teil des Produkts. Für den größten Teil des Verhaltens ist kein Schalter im Spiel, und das Repository entscheidet allein; jede Antwort grundsätzlich als bedingt zu behandeln hieße, gar nichts mehr zu behaupten.

Der Zugriff auf die Umgebung ist außerdem keine rein technische Frage. Die Produktionskonfiguration eines Kunden zu lesen berührt echte Daten und Vertraulichkeitsregeln, und nicht jede Organisation kann ihn denselben Fachbereichen öffnen.

Schließlich ist auch der Zustand eines Flags nur eine Momentaufnahme. Eine Antwort, die im Moment ihrer Formulierung stimmt, stimmt nach der ersten Änderung der Einstellung nicht mehr, ohne dass eine Änderung am Code darauf hingewiesen hätte.

Offene Fragen

• Wer erlaubt in einer Organisation einem Antwortsystem, die Produktionskonfiguration eines Kunden zu lesen, und unter welcher Kontrolle?
• Wie gibt man einem Kunden eine bedingte Antwort weiter, ohne dass sie für den, der sie in den Termin mitnimmt, unbrauchbar wird?