Die Hauptursache für "Works on My Machine"

Letztens habe ich einen Artikel über seltene Krankheiten gelesen. Gleich im Einleitungssatz stand etwas, was mich verwirrte: Seltene Krankheiten sind die häufigsten Krankheiten. Wie kann das sein?

Es macht Sinn: “selten” bezieht sich auf die Anzahl an Menschen, die von einer bestimmten Art von seltener Krankheit betroffen sind. “Am häufigsten” bezieht sich auf die Gesamtzahl der Menschen, die an einer beliebigen Art von seltener Krankheit leiden.

Genauso verhält es sich mit dem “Works on My Machine”-Problem “ Die Anzahl an unterschiedlichen Dingen die schief gehen können, wenn eine Software deployed wird, ist so groß, dass jedes einzelne Problem vielleicht nur unter ganz bestimmten Umständen auftritt und deshalb selten ist.

Das ist die Hauptursache: Die häufigsten Probleme sind seltene Probleme. Die meisten Probleme sind einzigartig. Betrachtet man ein Diagramm, das verschiedene Probleme darstellt, die beim Einsatz einer Software in verschiedenen Umgebungen aufgetreten sind, so ergibt sich ein Long-Tail von seltenen und einzigartigen Problemen.

Dieser Long-Tail an Problemen macht es extrem schwer, einen reliablen Deployment-Prozess sicherzustellen, der in verschiedenen Umgebungen funktioniert. Beim Deployment von Software in einer Produktionsumgebung wird dieses Problem in der Regel durch die Standardisierung der Deployment-Umgebung gelöst. Dies ist aber so gut wie unmöglich, wenn es um das lokale Deployment auf den Laptops der einzelnen Entwickler_innen geht. Selbst wenn das grundlegende Setup standardisiert ist, führt die schiere Vielfalt an Hardware und Software die auf den Laptops der Entwickler vorhanden sein kann – und wird – sehr oft zu Problemen beim lokalen Deployment der Software. Und die meisten dieser Probleme sind einmalig.

Probleme, die die Mehrheit oder auch nur mehrere Entwickler_innen betreffen, werden in der Regel schnell automatisiert. Das Problem ist, dass dann immer noch eine Menge Probleme übrig bleiben, die nur einen oder wenige Entwickler_innen betreffen. Die Behebung dieser seltenen Probleme im Rahmen der Deployment-Automatisierung rechtfertigt oft nicht den Zeit- und Arbeitsaufwand, der damit verbunden wäre. Die einzelnen Entwickler_innen müssen sich also selbst um diese Probleme kümmern.

Infolgedessen verbringen viele Entwickler_innen viel Zeit mit der Fehlersuche bei ihren lokalen Deployments. Je nach Komplexität kann dies einen kleinen oder großen Teil der Zeit ausmachen. Im Durchschnitt verbringen Entwickler_innen etwa 10 % ihrer Zeit mit der Fehlersuche in ihrer Entwicklungsumgebung. Manchmal ist diese Zahl noch viel höher.

Wie man den Long Tail los wird

Es gibt nur einen Weg, diese Zeitfresser loszuwerden: Indem man die Ursachen für mehrere Einzelprobleme angeht und Lösungen anbietet, die verhindern, dass sie überhaupt entstehen.

Die Containerisierung ist eine solche Lösung. Mit Containerisierung werden isolierte und standardisierte Umgebungen für die Ausführung von Softwarekomponenten bereitgestellt. Paketmanager, die es ermöglichen, mehrere Versionen eines Pakets nebeneinander zu installieren und zu verwenden (isolierte Pakete, z. B. Nix), sind ein weiterer Ansatz, der einen großen Teil des Long-Tails von Einzelproblemen abschneidet. Die Standardisierung von Entwickler_innen-Laptops ist ein oft erprobter Ansatz mit einmal mehr, einmal weniger guten Ergebnissen (Dazu: Probleme mit der lokalen Entwicklungsumgebung: Ist Containerisierung die Lösung?), aber zumindest konzeptionell ist er sinnvoll, weil versucht wird, eine zugrundeliegende Ursache anstelle von Tausenden von Einzelproblemen anzugehen.

In letzter Zeit hat ein anderer Ansatz an Popularität gewonnen: Remote Development Environments (RDEs) oder Cloud Development Environments (CDEs). Dabei handelt es sich um Arbeitsumgebungen, die remote bereitgestellt werden und in denen Softwareentwickler_innen die Software, an der sie arbeiten, zusammen mit allen benötigten Entwicklungswerkzeugen einsetzen und ausführen können.

Als vollumfassende Entwicklungsumgebungen gehen RDEs einige Schritte weiter als Container, da sie vom Betriebssystem aufwärts isolierte Umgebungen bieten. RDEs sind auch viel einfacher zu standardisieren, da sie neben zu den Laptops der Entwickler_innen existieren: Entwicklerinnen und Entwicklern steht es frei, auf ihren Laptops jede beliebige Hardware zu verwenden und jede beliebige Software zu installieren, ohne ihre standardisierten RDEs zu beeinträchtigen. Mit RDEs wird der Long-Tail einzigartiger Probleme fast vollständig beseitigt.

Wenn Sie mehr über RDEs/CDEs erfahren möchten, finden Sie hier einige zusätzliche Ressourcen: