Bus Number – das GitHub-Plugin, das meine Kollegen mir auszureden versuchten

 (scannedinavian.com)
1 Punkte von GN⁺ 2024-11-13 | 1 Kommentare | Auf WhatsApp teilen
  • Ein Entwickler wollte, angestoßen durch die Erfahrung, dass nach einer Entlassung der einzige Contributor an umsatzrelevantem Code verschwunden war, ein truck-factor-Plugin für GitHub Enterprise bauen, um in Projekten die unverzichtbaren Personen zu finden
  • Kollegen warnten, dass diese Kennzahl schnell unter Goodhart’s Law fallen und statt zum Schutz wichtiger Personen zu einem Management-Tool werden könnte, um herauszufinden, wen man entlassen kann
  • Das ursprüngliche Truck-Factor-Repository und die Daten waren weiterhin nutzbar, aber das Datum der Datenerhebung war unklar, und die README-Anweisungen ließen sich nicht unverändert reproduzieren, sodass manuell nachgebessert werden musste
  • Die Neuberechnung erfolgte, indem mehrere GitHub-Repositories mit gnu parallel geklont und anschließend Java-Code ausgeführt wurde; für den Linux kernel ergab sich ein truck factor von 12 ohne linguist-Filter und 8 mit Filter
  • Damit lag das Ergebnis unter den Werten aus dem ursprünglichen Paper – 90 im Preprint von 2015, 57 in der veröffentlichten Fassung – sodass sich kaum sagen lässt, dass sich der bus factor des Linux kernel verbessert hat

Bus Factor und die riskante Plugin-Idee

  • Bus Factor oder Truck Factor bezeichnet die minimale Zahl von Teammitgliedern, die plötzlich ausfallen müssten, bevor ein Projekt wegen fehlenden Wissens zum Stillstand kommt
  • Ausgangspunkt war ein Entlassungsprozess im Unternehmen um 2015, bei dem der einzige Contributor an einem Teil der Codebasis, die dem Unternehmen Geld einbrachte, entlassen wurde
  • Daraus entstand die Idee eines GitHub-Enterprise-Plugins, das berechnet, wen man nicht entlassen darf
  • Als dieses Plugin in einem fünfminütigen Lightning Talk an einem Donnerstagnachmittag vorgestellt wurde, meinten Kollegen, Manager könnten es als Werkzeug verwenden, um herauszufinden, wen sie entlassen können
  • Im Kern dieser Reaktion stand Goodhart’s Law

Frühere Truck-Factor-Forschung und der Reproduktionsversuch

  • Die ursprüngliche Studie berechnete für mehrere populäre GitHub-Projekte, wie viele Personen ausfallen müssten, bevor das Projekt zum Erliegen kommt
  • Dazu gehörte auch der Linux kernel
  • Zu Beginn des Textes heißt es, der erste Preprint habe für Linux angegeben, dass 80 Personen ausfallen müssten; später werden die Werte als 90 im Preprint von 2015 und 57 in der vollständigen Veröffentlichung zusammengefasst
  • Gemeinsam mit mclare wurde versucht, rund zehn Jahre später zu prüfen, ob sich der truck factor verbessert hat, indem die Ergebnisse reproduziert wurden
  • Das GitHub-Repository der ursprünglichen Autoren war weiterhin verfügbar

Einschränkungen bei Daten und Laufzeitumgebung

  • Die Paper-Daten wurden als JSON bereitgestellt, und die ursprüngliche Visualisierung basierte auf einem scrapbaren CSV
  • Allerdings ließ sich das Datum der Datenerhebung nicht feststellen
  • Die README-Anweisungen funktionierten nicht mehr unverändert, daher musste die Ausführung mithilfe von GitHub-Issues angepasst werden
  • Aus der ersten Spalte des ursprünglichen CSV wurde eine Liste der GitHub-Repositories extrahiert und anschließend alles geklont
  • Mit gnu parallel wurden mehrere git clone-Befehle gleichzeitig ausgeführt

Hürden mit gnu parallel, linguist und NixOS

  • Für gnu parallel wurde -j 8 gesetzt, trotzdem wurden offenbar alle 32 Kerne des Laptops ausgelastet
  • Sichtbar waren gleichzeitig 8 git clone-Prozesse, dazu aber zahlreiche git index-pack-Prozesse, die sämtliche Kerne nutzten
  • Als mögliche Ursache wurde vermutet, dass git index-pack ein geforkter Unterprozess ist und parallel deshalb weitere git clone-Prozesse startet
  • Der Truck-Factor-Code verwendet GitHubs linguist, um Dokumentationsdateien auszuschließen
  • In der NixOS-Umgebung ließ sich die Installation der Ruby Gems mangels Ruby-Erfahrung nicht rechtzeitig lösen; gesucht wurden daher Hinweise zur Installation des linguist-Plugins in einem Nix flake oder ein Pull Request

Das konkrete Verfahren zur Neuberechnung

  • Das Original-Repository wurde geforkt, lokal geklont und dann gemäß README mit angepasstem Ablauf ausgeführt
  • Mit mvn package wurde der Java-Quellcode in ein jar kompiliert
  • Zunächst wurden die einzelnen Schritte mit dem GitHub-Repository von numpy getestet, danach erfolgte die Neuberechnung über alle Repositories
  • mclare lud das CSV der ursprünglichen Visualisierung herunter und wandelte die erste Spalte in eine Liste von GitHub-Repositories um
  • Der Ablauf sah so aus
    • Mit parallel -j 8 git clone ::: $(cat ../meta/repo_list.txt) wurden die Repositories geklont
    • Anschließend wurde in das Verzeichnis gittruckfactor/scripts gewechselt, um awk-Fehler zu vermeiden
    • Mit commit_log_script.sh wurden für jedes Repository die Git-Commit-Informationen extrahiert
    • Danach wurde gittruckfactor-1.0.jar ausgeführt, um die extrahierten Commit-Daten zu verarbeiten
  • Über die schnelle Gigabit-Internetverbindung zu Hause dauerte das sequenzielle Klonen aller Repositories 17,5 Minuten
  • Die Verarbeitung der einzelnen Repositories scheint ebenfalls ungefähr 18 Minuten gedauert zu haben

Ergebnis der Neuberechnung für den Linux kernel

  • Die Beispielausgabe für den Linux kernel lautete TF = 12, coverage = 49.98%
  • Zu den TF authors gehörten unter anderem Linus Torvalds, Mauro Carvalho Chehab, Rob Herring, Thomas Gleixner und Krzysztof Kozlowski
  • Linus Torvalds wurde mit 5.712 Dateien und 6,59 % ausgewiesen
  • Ohne das linguist-Plugin, also ohne das Herausfiltern von Dokumentation und Third-Party-Libraries, ergab sich für den Linux kernel ein truck factor von 12
  • Nachdem mclare das linguist-Plugin auf dem eigenen System installiert hatte, ergab sich für den Linux kernel ein truck factor von 8

Nicht berücksichtigte Faktoren und nächste Prüfungen

  • In diese Berechnung floss der Review-Prozess nicht ein
  • Mit wachsender Erfahrung müssen Entwickler oft mehr Reviews übernehmen, statt selbst direkt Code über die Tastatur zu schreiben
  • Zusätzlich sollen unter anderem folgende Punkte geprüft werden
    • ob die truck-factor-Berechnung co-authored-by und Reviewer-Header aus Git reflektiert
    • falls nicht, ob sich das in die Berechnung einbeziehen lässt
    • warum sich der Linux-Wert nach zehn Jahren so stark verändert hat
    • ob es einen Unterschied macht, dass zum Zusammenführen von Entwickler-Aliasen – wie im Original-Paper – kein Levenshtein distance von 1 angewendet wurde
    • ob dasselbe Code-Set noch immer 80 ergeben würde, wenn das Linux-kernel-Repository auf Mitte 2015 ausgecheckt wird
    • ob sich wegen einer Algorithmus-Aktualisierung im Jahr 2016 spätere Werte erneut berechnen lassen
  • Ein Blick auf die 156 Zitierungen des Original-Papers könnte zeigen, ob es bessere Berechnungsansätze gibt
  • Neuere große Projekte wie Rust waren im Paper von 2015 noch nicht enthalten, daher ließen sich heutige populäre Projekte mit ihrer früheren Entwicklung vergleichen
  • Man könnte auch ein Skript bauen, das für beliebige Git-Repositories die truck number pro Jahr ermittelt

Ein noch niedrigerer Bus Factor

  • Die eigentliche Frage war, ob sich der truck factor mit der Zeit verbessert hat
  • Das Ergebnis deutet eher darauf hin, dass er sich nicht verbessert, sondern verschlechtert hat
  • Für den Linux kernel lagen die diesmal berechneten Werte deutlich unter denen des Original-Papers
  • Je nachdem, ob Dokumentation und Third-Party-Libraries herausgefiltert wurden, sank das Ergebnis für den Linux kernel von 12 auf 8
  • Weitere Visualisierungen und Details finden sich im Beitrag von mclare

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2024-11-13
Meinungen auf Hacker News

  • Eine der Funktionen von https://codescene.com/ ist genau das
    Es findet Wissensinseln und verknüpft sie mit häufig geändertem Code, um riskante Hotspots zu identifizieren, bei denen es viele Änderungen, aber wenig Wissensverteilung gibt
    Wenn jemand seine Kündigungsabsicht äußert, kann man leicht sehen, welchen Code nur diese Person kennt, und entsprechend einfach einen Übergabeplan erstellen
    Ich habe nie darüber nachgedacht, dass das missbraucht werden könnte; ursprünglich ist es ein Tool für Sichtbarkeit. Ein Manager, der es so nutzt, ist ein schlechter Manager, und wenn er schon so jemand ist, wird dieses Tool daran nichts ändern

    • Man sollte „Missbrauch“ nicht zu naiv betrachten. Nehmen wir an, man gehört zum Nachrichtendienst eines Landes. Angenommen, ein Land namens Tussia, dem der Zugriff auf den wichtigen Kernel Kinux verwehrt ist, der in militärischer Ausrüstung weltweit eingesetzt wird, erfährt, dass die Person im Büro nebenan ein Projekt gestartet hat, um diesen Kernel für den internen Gebrauch des eigenen Landes zu forken
      Wenn man auf eine Beförderung aus ist, könnte man bei der zuständigen Abteilung „8 Agentinnen mit Spezialtraining darin, sich mit Nerds anzufreunden“ anfordern und vorsorglich auch 8 Dosen Polonium für den Fall des Scheiterns
      Das mag wie reine Fiktion klingen, aber ich kenne den CEO eines Unicorn-Startups, das Seed-Finanzierung suchte und tatsächlich etwas erlebt hat, das dem ersten Teil entspricht
    • Ich habe drei Arbeitsplätze erlebt, an denen Pluralsight Flow eingeführt wurde; in zwei davon begannen Manager sofort, die Kennzahlen für Feedback, Leistungsbeurteilungen und Personalentscheidungen zu verwenden
      Beim dritten Arbeitgeber erkannten die Entwickler diese Entwicklung schon von weitem und verweigerten die Nutzung des Tools bzw. die Bewertung selbst
      Solche Tools sind absurd teuer, sodass die Seite, die sie genehmigt hat, irgendwie einen Return on Investment herausholen muss. Da es keine vernünftige Methode gibt, Produktivität, Output oder Wissenssilos zu messen, läuft es am Ende auf Dinge hinaus wie: „Jose hatte diese Woche wenige PRs“
    • Der Zweck der Sichtbarkeit an sich ist großartig, aber nur, solange es in diesem Bereich bleibt
      Das Problem ist, dass Entwickler das ebenfalls sehen und versuchen könnten, in Zielprojekte oder Komponenten zu wechseln, um auf die Liste der unkündbaren Mitarbeiter zu kommen. Idealerweise könnten sich Beschäftigte gemeinsam bewegen und den Truck Factor auf 0 bringen, sodass es schwer wird, irgendjemanden zu entlassen
      Natürlich wäre das fast vollständige Zeitverschwendung und würde den ursprünglichen Punkt der Kollegen des Bloggers belegen, dass man „sofort in Goodhart’s Law hineinläuft“
    • Eine externe Beratungsfirma könnte das auch nutzen, um einem Unternehmen bei Entlassungen zu helfen. Das ist möglich, egal wie gut ein Manager ist

  • Bei Amazon kann man solche Zahlen in den Codesystemen leicht als Bericht sehen, den jeder Manager ausführen kann, und es gibt viele andere Möglichkeiten zu prüfen, was Teams tun und welche Risiken bestehen. Persönlich halte ich das für nützlich
    Der Bus Factor ist nur eine Perspektive; aus anderen Blickwinkeln hilft er dabei, Silos, Entwickler, die nicht mit anderen zusammenarbeiten, und Bereiche zu finden und zu beheben, in die man Entwickler nur schwer versetzen kann
    Manche Entwickler fürchten Ersetzbarkeit und glauben, ein System, das nur sie kennen, sei Jobsicherheit. Umgekehrt ist das aber ein technisches Risiko und kann ein Faktor sein, der gute Entwickler daran hindert, zu wichtigeren Projekten zu wechseln. Es ist auch ein Weg, etwas anderes machen zu können, wenn man ein ungeliebtes System satt hat

    • Ich habe keine Angst vor Ersetzbarkeit. Wenn ein Ort mich nicht will, will ich dort auch nicht sein
      Allerdings erzeugt die Idee der Ersetzbarkeit viel Overhead und verhindert, dass talentierte Leute ihre maximale Leistung einbringen. Denn tatsächlich sind sie nicht ersetzbar
      An manchen Orten ist das nötig, aber an anderen wird Prozess-Overhead zu einem viel größeren Risiko für den Projekterfolg als der Bus Factor
    • Ich kenne einen Entwickler, dem Versetzung und Beförderung verweigert wurden, weil man seine Stelle nicht leicht nachbesetzen konnte
      Das Ende war seine Kündigung innerhalb von drei Monaten
    • „Wenn du nicht ersetzt werden kannst, kannst du nicht befördert werden“
    • Aus Sicht eines Mitarbeiters, dessen Hauptziel nicht die Gewinnoptimierung des Unternehmens ist, ist die Vorstellung, dass ein System, das nur er kennt, Jobsicherheit bedeutet, durchaus eine realistische Strategie
    • Während meiner gesamten Karriere habe ich versucht, mich und andere Entwickler so ersetzbar wie möglich zu machen. Ein großer Teil der Digitalisierungsarbeit besteht ohnehin genau darin, und außerdem ist der Umgang mit Wissenssilos frustrierend
      Einer der Gründe, warum ich auch im Backend viel TypeScript einsetze, ist, dass ein kleines Team dadurch nur eine Sprache kennen muss. So kann ein Frontend-Entwickler im Urlaub tatsächlich abschalten, und jemand anderes kann einspringen. Wenn jemand den Job wechselt, tut es weniger weh
      Das war nie ein Problem, und ich sehe Ersetzbarkeit als Teil eines gesunden Systems. Nach ein paar Jahren im Management lernt man als Erstes: „Jeder ist ersetzbar, es ist nur eine Kostenfrage.“ Wenn das Wissensniveau zu hoch ist, kann es sich daher sogar nachteilig auswirken, weil das Management versuchen wird, dieses Risiko zu senken. Vor allem Entlassungen aus wirtschaftlichen Gründen sind zudem ziemlich zufällig
      Trotzdem möchte ich nicht an einem Ort arbeiten, der solche lächerlichen Kennzahlen verwendet. Je mehr Bürokratie man darum legt, gute Arbeit zu leisten, desto geringer ist die Wahrscheinlichkeit, dass ich dort mitarbeiten möchte. Solche Dinge bringen Menschen leicht dazu, Kennzahlen zu gamen, statt gute Arbeit zu leisten, und schaffen eine Kultur, die Produktivität und Qualität schadet

  • gnu parallel führt wie angefordert 8 git clone-Jobs gleichzeitig aus, und jedes git clone startet nach eigenem Ermessen viele index-pack-Threads.
    Hier hilft es, pack.threads per git config vorübergehend auf 1 zu setzen.

    • Das ist ein immer häufiger auftretendes Problem. Beide Ebenen parallelisieren jeweils auf die Zahl der CPUs oder Kerne und versuchen, die ganze Maschine zu nutzen; in der inneren Ebene entstehen dann N² Threads/Prozesse.
      Weil das quadratisch wächst, wird das Problem umso schlimmer, je mehr CPUs man hat. Bei 32 Kernen sind das 32² = 1024; tatsächlich waren bei Parallel hier 8 angegeben, also hätte es vermutlich bei höchstens etwa 256 index-pack-Prozessen geendet. Trotzdem braucht man viel Speicher, um das zu verkraften, und real bringt es keinen Vorteil.
      Die Lösung ist, nur eine der beiden Ebenen zu parallelisieren.
      Zu pack.threads sagt man git-config: Gibt die Anzahl der Threads an, die beim Suchen nach den besten Delta-Matches erzeugt werden sollen; dafür muss git-pack-objects(1) mit pthreads kompiliert sein. Andernfalls wird die Option mit einer Warnung ignoriert. Sie dient dazu, die Pack-Zeit auf Mehrprozessormaschinen zu verkürzen, aber der für das Delta-Suchfenster benötigte Speicher wird mit der Anzahl der Threads multipliziert. Bei 0 erkennt Git die CPU-Anzahl automatisch und setzt die Thread-Zahl entsprechend.
    • Statt das temporär per git config zu setzen, kann man einfach git -c pack.threads=1 clone verwenden: https://git-scm.com/docs/git#Documentation/git.txt--cltnameg...

  • Diese Interpretation finde ich nicht besonders gut. Ich sehe den Artikel als Text für alle Engineering-Führungskräfte.
    Der Bus-Faktor bedeutet, wie sehr ein Team leidet, wenn jemand im Team, oder man selbst, von einem Bus überfahren wird.
    Der ideale Bus-Faktor für jedes Teammitglied ist 0. Zunächst klingt das vielleicht nach „Macht alle austauschbar“, aber tatsächlich ist es fast das Gegenteil, und genau darum geht es.
    Ein Team sollte so gut sein, dass es a) autonom ist und b) keine Mysterien hat. Im Idealzustand versteht jeder, wie alles funktioniert. Neue Mitarbeiter sollten sofort anfangen können, Wert zu schaffen, und ausscheidende Mitarbeiter sollten beruhigt sein, weil keine unbekannten Bereiche zurückbleiben.
    Ein ideales Team, in dem jeder einen BF von 0 hat, ist wünschenswert. Es bedeutet, dass Teammitglieder ersetzbar sind und dass jedes Teammitglied die Lücke füllen kann, wenn jemand krank wird, Urlaub nimmt, tatsächlich geht oder entfernt wird.
    Noch wichtiger ist, dass ein BF von 0 ein Ausdruck von Einfachheit ist. Software, Build-, Test- und Deployment-Pipelines, Dokumentation und Support-Strukturen sollten kohärent und konsistent sein. Wissen in einzelnen Teammitgliedern zu siloieren ist schlecht, und jeder sollte bauen und deployen können.
    Ein BF von 0 ist ein gesundes Signal, lässt sich aber niemals über die Zahl der E-Mails, Commits, PRs, Codezeilen, Antwortzeiten oder GitHub-Heatmaps messen. Solche Metriken zeigen gar nichts und sind vielmehr schädliche, furchtbare Kennzahlen.
    Menschen anhand solcher Metriken zu bewerten, ist nicht besser als Affen vor Schreibmaschinen zu setzen. Mehr Startups sollten das hören.

    • Ich habe den Bus-Faktor immer andersherum verstanden: „Wie viele Leute müssen von einem Bus überfahren werden, damit das Projekt nicht mehr weitergeführt werden kann?“ In diesem Sinn wäre der Optimalwert gleich der Teamgröße.
      Es scheint dasselbe Konzept zu sein, aber es überrascht mich, dass die Zahl nicht immer in dieselbe Richtung verwendet wird.
    • Ich habe einmal an einem Projekt gearbeitet, bei dem es weltweit nur eine Handvoll Menschen mit einer bestimmten Fähigkeit gab. Zu diesem Zeitpunkt war der Bus-Faktor ganz klar 1.
      Bei Projekten, die die Grenzen des Möglichen verschieben, ist Einfachheit manchmal keine Option. Natürlich ist das nur ein kleiner Anteil aller Softwareprojekte, aber wenn man etwas noch nie Dagewesenes macht, ist „Wie zum Teufel schaffen wir das überhaupt?“ eine größere Sorge, als den Code so einfach wie möglich zu halten.
      Das heißt nicht, dass schlechte Codequalität in Ordnung wäre. Aber wenn man schwierige Dinge tut, braucht man manchmal komplexen Code; erst ein paar Generationen später kristallisieren sich dann Design Patterns heraus, mit denen sich dieselbe schwierige Aufgabe mit weniger komplexem Code lösen lässt. Das kann auch erst zehn Jahre später der Fall sein.
    • Wenn man vom ersten Tag an nur Dinge baut, bei denen jeder den Code verstehen kann und kein Domain-Wissen nötig ist, worin besteht dann das Wertversprechen dieses Produkts oder Teams?
      Wenn das Komplexeste, was man bauen kann, ungefähr eine Todo-App ist, schafft man meiner Meinung nach nicht viel Wert für die Gesellschaft.
    • Wer gut in seiner Arbeit ist und Selbstvertrauen hat, versucht aktiv, den eigenen Bus-Faktor zu senken.
      Ein hoher Bus-Faktor bedeutet, dass dein Arbeitgeber dich eher wegen deiner bisherigen Arbeit festhält als wegen deines zukünftigen Potenzials.
    • So denkt das Militär. Es geht davon aus, dass es auch nach Verlusten weiter funktionieren muss.

  • Die zentrale Aussage des ursprünglichen Papers ist dieser Teil:
    „Unsere Schätzung beruht auf einer Coverage-Annahme. Wenn die aktuelle Menge der Autoren weniger als 50 % der aktuellen Dateimenge des Systems abdeckt, ist es wahrscheinlich, dass das System erhebliche Verzögerungen erleidet oder zum Stillstand kommt.“
    Dabei ist der Autor einer Datei als Nutzer definiert, der nach einer vorab berechneten Gewichtung einen bedeutenden Beitrag zu dieser Datei geleistet hat.

  • Einerseits würde es mich eher überraschen, wenn diese Art von Dashboard-Metrik nicht schon in irgendeiner Enterprise-Software stecken würde. Die Geschäftsführung in meiner früheren Firma fragte tatsächlich einmal, ob man einen Tagesbericht erstellen könne, der zeigt, wer in der Abteilung die meisten E-Mails gesendet und empfangen hat.
    Ich habe abgelehnt, weil mir nicht gefiel, wohin das führen würde, aber ein anderer Kollege hat es gebaut. Wie zu erwarten war, war die Person mit den meisten empfangenen und gesendeten E-Mails der Systemadministrator, weil sein Account als automatischer Absender für mehrere Server eingerichtet war. Er schickte sich selbst Hunderte von Benachrichtigungs-E-Mails pro Tag, zusätzlich zu abonnierten Newslettern und Zusammenfassungen.
    Andererseits klingt es ziemlich fies, ein Hobbyprojekt trotzdem durchzuziehen, obwohl alle Kollegen darum gebeten haben, nichts zu tun, was ihre Jobs beeinträchtigen könnte.

    • Als die Kollegen 2015 baten, es nicht zu machen, habe ich es nicht gebaut.
      Ich möchte nur sehen, ob die Open-Source-Software, die ich nutze, Wissen gut genug verteilt hat, um ihre Überlebensfähigkeit zu erhöhen.
      Diese fiese Sache habe ich abgelehnt.
    • Eine völlig unsinnige Metrik.

  • „Je weiter Entwickler die Karriereleiter hinaufsteigen, desto weniger sollten sie selbst an der Tastatur arbeiten und desto mehr Reviews machen“ halte ich für ein verbreitetes Missverständnis in Tech-Unternehmen.
    Es geht nicht darum, großartige Entwickler in mittelmäßige Manager zu verwandeln.

    • Genau. Es gibt Tech Leads, die hervorragend Code schreiben können, deren Fähigkeiten in Bereichen wie Leadership oder Feedback aber miserabel sind.
      Als Senior Developer wäre er viel besser aufgehoben als als Tech Lead. Man kann sich kaum vorstellen, wie sehr das Team leiden würde, wenn er Manager würde.
    • Wenn man Code Reviews als „Management“ betrachtet, ist das ziemlich ernsthaft besorgniserregend.

  • Die traurige Ironie daran ist, dass die Frage immer noch falsch gestellt ist.
    Wenn ein Startup Entlassungen vornehmen muss, lautet die Frage nicht: „Wen können wir entlassen und trotzdem das bestehende Geschäft aufrechterhalten?“, sondern: „Welches Team kann schnell genug die nächste Version des Produkts bauen, damit wir nicht untergehen?“
    Jede Weggabelung ist am Ende eine Weggabelung, und viele Unternehmen sind gestorben, weil sie sich nicht schnell genug für einen Weg entschieden haben.

  • CPAN verfolgt den Bus-Faktor schon seit Langem. Zum Beispiel zeigt https://metacpan.org/pod/Moose in der linken Info-Spalte einen Bus Factor von 5 an.

  • Wir nennen das lieber Lotterie-Faktor.
    Gemeint ist: Kann das Projekt weiterlaufen, selbst wenn jemand im Lotto gewinnt und auf eine tropische Insel ohne Strom- und Kommunikationsnetz zieht?
    So klingt es weniger unheimlich.

    • Ein Lottogewinner kündigt zwei Wochen vorher, und wenn es wirklich nötig ist, kann man ihn später auch noch anrufen.
      Jemand, der von einem Bus angefahren wird, ist sofort weg. Das ist nicht dasselbe.
    • Gute Mitarbeiter wollen ihr Projekt übergeben und auch Fragen beantworten, aber man muss auch für Fälle vorsorgen, in denen das nicht möglich ist.
    • Einen Jobwechsel euphemistisch als sudden death zu bezeichnen, hinterlässt keinen guten Nachgeschmack.
      Manche mögen Sportmetaphern nicht, aber ich finde sie zumindest besser als Militärmetaphern.
      Da es ohnehin oft genug keine ordentliche Übergabe gibt, ist die Plötzlichkeit selbst vielleicht gar kein so entscheidender Faktor.
    • Dass jemand von einem Bus angefahren wird, könnte sogar wahrscheinlicher sein, also sollte man auch diese Möglichkeit berücksichtigen.
    • Ich kenne niemanden, der den großen Jackpot geknackt hat oder von einem Bus angefahren wurde, aber ich kenne mehrere Leute, die als Krypto-Reiche gekündigt haben.