Bus-Faktor 1: Wenn nur eine Person das System versteht

Es gibt in fast jedem gewachsenen Unternehmen eine Person, die man nicht in den Urlaub schicken möchte. Sie kennt das alte Bestellsystem, weiß, warum in Modul X seit 2016 dieser eine seltsame Workaround steht, und ist die Einzige, die das Deployment ohne Schweißausbruch durchzieht. Das nennt man den Bus-Faktor 1: Wenn diese eine Person ausfällt, steht das System still. Der Name ist zynisch gemeint. Er beschreibt, wie viele Menschen von einem Bus erfasst werden müssten, bevor ein Projekt nicht mehr wartbar ist. Bei einem Bus-Faktor von 1 reicht ein Krankenschein.

Was bedeutet Bus-Faktor 1 konkret?

Der Bus-Faktor beschreibt, wie viele Personen zentrales, nicht dokumentiertes Wissen über ein System verlieren dürften, bevor die Weiterentwicklung oder Wartung praktisch unmöglich wird. Ein Bus-Faktor von 1 bedeutet, dass genau eine Person dieses Wissen exklusiv hält.

In der PHP-Welt begegnet mir das ständig. Eine Anwendung läuft seit acht, zehn, manchmal fünfzehn Jahren stabil im Produktivbetrieb. Sie verdient Geld. Aber das Wissen darüber, warum sie funktioniert, existiert nicht in Tests, nicht in einem Wiki und nicht in lesbarem Code, sondern nur im Kopf eines einzelnen Entwicklers. Oder eines externen Dienstleisters, den seit Jahren niemand mehr angerufen hat.

Warum ist ein Bus-Faktor 1 so gefährlich?

Ein Bus-Faktor 1 ist gefährlich, weil das Risiko unsichtbar bleibt, solange nichts passiert. Das System läuft ja. Erst wenn die Schlüsselperson kündigt, krank wird oder in Rente geht, wird aus einem latenten Risiko ein akuter Notfall, den niemand mehr abfedern kann.

Die Kosten zeigen sich in mehreren Formen:

• Stillstand bei Änderungen. Selbst kleine Anpassungen bleiben liegen, weil niemand sonst sich in den Code traut. Ein neues Mehrwertsteuer-Feld oder eine geänderte Schnittstelle wird zum Monatsprojekt.
• Erpressbarkeit. Ich sage das ungern so deutlich, aber ein einzelner Wissensträger verschiebt Machtverhältnisse. Das ist selten böse Absicht, aber es ist eine ungesunde Abhängigkeit.
• Sicherheitslücken bleiben offen. Wenn niemand außer einer Person den Code versteht, wird kein Security-Update eingespielt, aus Angst, etwas kaputtzumachen. Eine alte Symfony- oder Laravel-Version bleibt dann jahrelang ungepatcht.
• Der Totalausfall. Fällt die Person unvorhergesehen aus, steht ein Team vor einer Codebasis ohne Landkarte. Das ist der teuerste Moment überhaupt.

Das System ist nicht das Problem — der Zugang zum Wissen ist es

An dieser Stelle fällt oft der Reflex: "Dann bauen wir es eben neu, sauber, dokumentiert." Ich halte das in den allermeisten Fällen für die teuerste und riskanteste Entscheidung, die man treffen kann.

Denn ein System, das seit Jahren im Produktivbetrieb läuft, ist kein Müll. Es ist der Beweis, dass die Fachlogik funktioniert. In diesem Code steckt jahrelange, teuer erkaufte Erfahrung: jeder Sonderfall, jede Ausnahme, jeder krumme Geschäftsprozess, den ein echter Kunde irgendwann ausgelöst hat. Das Problem ist fast nie die Fachlogik. Das Problem ist der Code drumherum, der diese Logik unlesbar verpackt, und der Umstand, dass das Wissen nie aus dem Kopf in die Codebasis zurückgeflossen ist.

Eine Neuentwicklung wirft dieses Wissen weg und beginnt bei null, meist mit derselben Person als einziger Quelle. Der Bus-Faktor bleibt 1, nur mit einem höheren Budget.

Wie senkt man den Bus-Faktor in einer Legacy-PHP-Anwendung?

Den Bus-Faktor senkt man, indem man Wissen schrittweise aus dem Kopf der Schlüsselperson in die Codebasis überführt: durch Tests, Dokumentation und behutsames Refactoring am laufenden System. Nicht durch einen großen Wurf, sondern durch viele kleine, sichere Schritte.

In der Praxis gehe ich meist in dieser Reihenfolge vor:

1. Charakterisierungs-Tests schreiben. Bevor irgendetwas angefasst wird, wird das aktuelle Verhalten in automatisierten Tests festgehalten, so wie es ist, inklusive der Macken. Diese Tests dokumentieren, was das System tatsächlich tut, und geben ein Sicherheitsnetz für jede spätere Änderung.
2. Das System zum Laufen bringen, ohne die eine Person. Ein reproduzierbares Setup mit Docker, dokumentierte Umgebungsvariablen, ein nachvollziehbarer Deployment-Prozess. Wenn ein neuer Entwickler die Anwendung an einem Vormittag lokal starten kann, ist bereits viel gewonnen.
3. Das implizite Wissen abgreifen, solange es noch da ist. Strukturierte Interviews mit der Schlüsselperson, während man gemeinsam durch den Code geht. Warum steht dieser Workaround hier? Welcher Kunde hat diesen Sonderfall ausgelöst? Dieses Wissen wandert direkt in Tests und Kommentare.
4. Gezielt refaktorieren, nicht neu schreiben. Die verworrensten und riskantesten Stellen zuerst entwirren, in kleinen, durch Tests abgesicherten Schritten. Die bewährte Fachlogik bleibt erhalten, nur der Code drumherum wird lesbar.
5. Abhängigkeiten und Sicherheit aktualisieren. Sobald Tests greifen, lassen sich alte PHP-, Symfony- oder Laravel-Versionen und veraltete Composer-Pakete schrittweise anheben. Genau die Updates, die vorher aus Angst liegen blieben.

Wie erkennt man einen Bus-Faktor 1, bevor es zu spät ist?

Man erkennt einen Bus-Faktor 1 an ein paar wiederkehrenden Warnsignalen im Alltag. Wenn Sie mehrere davon wiedererkennen, ist das Risiko real und nicht theoretisch.

• Es gibt genau eine Person, die man bei Problemen mit dem System anruft, immer.
• Niemand außer dieser Person kann die Anwendung lokal starten oder deployen.
• Es existieren keine oder kaum automatisierte Tests.
• Dokumentation ist veraltet, lückenhaft oder gar nicht vorhanden.
• Sicherheitsupdates werden aufgeschoben, weil niemand die Nebenwirkungen einschätzen kann.
• Die Antwort auf "Warum ist das so gebaut?" lautet regelmäßig "Das weiß nur der Kollege".

Wichtig ist die Haltung dabei. Ein Bus-Faktor 1 ist kein Vorwurf an die betroffene Person. Sie hat das System oft über Jahre am Leben gehalten. Das Problem ist organisatorisch, nicht persönlich, und genau so sollte man es angehen. Wer die Schlüsselperson beschuldigt, verliert ihre Kooperation, und mit ihr das Wissen, das man dringend braucht.

Ehrlicher Praxis-Tipp

Fangen Sie nicht mit dem Code an, sondern mit einem einzigen Satz auf einem Blatt Papier: Was passiert konkret, wenn Person X ab morgen nicht mehr erreichbar ist? Wenn Sie diese Frage nicht ruhig beantworten können, haben Sie das wichtigste Ergebnis schon. Der nächste konkrete Schritt ist fast immer derselbe und der günstigste überhaupt: die ersten Charakterisierungs-Tests für den kritischsten Programmteil schreiben. Das kostet wenig, riskiert nichts am Produktivsystem und macht das Wissen zum ersten Mal überprüfbar. Alles Weitere baut darauf auf.

Genau bei dieser Arbeit, das Wissen aus einem Kopf zurück in eine wartbare Codebasis zu holen, ohne das bewährte System wegzuwerfen, unterstützt LegacyWerk.