Bewusst langweilige Software ausliefern

Früh in meiner Laufbahn habe ich Neuheit mit Qualität verwechselt. Ein neuer Datenspeicher, eine exotische Queue, ein Framework, das seit drei Wochen auf Hacker News steht — jedes davon fühlte sich nach Fortschritt an. Die meisten wurden zu dem, weswegen ich um drei Uhr nachts angerufen wurde.

Heute optimiere ich auf eine andere Eigenschaft: Wie schnell versteht die nächste Entwicklerin das hier und kann es gefahrlos ändern? Diese Frage führt in aller Regel zu langweiliger, gut verstandener Technik — und sie war bisher der beste Vorhersagewert dafür, ob ein System gut altert.

Langweilig ist ein Vorzug, kein Kompromiss

Langweilige Technik hat eine große Fläche an Vorerfahrung. Wenn Postgres etwas Überraschendes tut, sind zehntausend Leute vorher darüber gestolpert und haben es aufgeschrieben. Wenn Ihre selbstgebaute Konsensschicht etwas Überraschendes tut, sind Sie die Dokumentation.

Das zählt genau dann am meisten, wenn es brennt:

• Die Fehlerbilder sind bekannt und auffindbar.
• Einstellungen sind leichter, weil die Fähigkeiten bereits existieren.
• Das Umfeld — Backups, Migrationen, Observability — ist ausgereift.

Nichts davon ist glamourös. Alles davon summiert sich.

Wann ich meine Regel breche

Standardmäßig langweilig heißt nicht immer langweilig. Ich gebe Neuheitsbudget aus — was Dan McKinley Innovation Tokens nannte, von denen man etwa drei hat —, wenn drei Dinge zusammenkommen:

1. Das Problem gehört wirklich zum Kern des Geschäfts und ist nicht nebensächlich.
2. Die langweilige Option hat eine konkrete, gemessene Obergrenze, an die ich bereits gestoßen bin.
3. Ich kann das Neue hinter einer Schnittstelle einkapseln, die ich in einer Woche wieder herausreißen könnte.

Eine gute Architektur macht die umkehrbaren Entscheidungen billig und die unumkehrbaren selten.

Wenn ich die Linie nicht ziehen kann, an der das riskante Bauteil endet, bin ich noch nicht so weit, es hinzuzufügen.

Der Test, den ich tatsächlich anwende

Bevor ich etwas in einen Stack aufnehme, frage ich: Wenn das zum denkbar schlechtesten Zeitpunkt kaputtgeht — weiß ich, wie ich es repariere, und kann ich diese Reparatur jemandem erklären, der es noch nie gesehen hat?

Lautet die Antwort nein, ist die interessante Wahl meistens die falsche. Liefern Sie die langweilige Variante aus, messen Sie sie — und lassen Sie die Daten entscheiden, wann es Zeit für etwas Schärferes ist, nicht das Changelog.