Warum Bug-Fixing Unternehmen ein Vermögen kostet

Warum ist Bug-Fixing tatsächlich so mühsam?

Jani Hartikainen von CodeUtopia beschreibt die einzelnen Schritte, die bei einem Bug-Fix durchlaufen werden müssen (Aus dem Englischen übersetzt):

1. Zunächst müssen wir das Problem verstehen. Das bedeutet, dass wir wissen müssen, was schief läuft und wo, und was stattdessen passieren soll.
2. Als Nächstes müssen wir den Fehler reproduzieren. Ein typischer Fall könnte sein, dass wir in die Anwendung gehen, an der wir arbeiten, und ein paar Dinge anklicken, um zu sehen, was passiert.
3. Dann müssen wir herausfinden, welcher Teil des Codes das Problem verursacht. Dazu können wir in der Regel Debugging-Tools verwenden.
4. Sobald wir den Teil des Codes gefunden haben, der das Problem verursacht, müssen wir die Grundursache ermitteln. Je nach Komplexität des Problems kann die Schwierigkeit dabei sehr unterschiedlich sein.
   Nachdem wir die Grundursache identifiziert haben, können wir den Fehler beheben.
5. Schließlich müssen wir sicherstellen, dass der Fehler tatsächlich behoben ist. Dies geschieht in der Regel durch einen erneuten Versuch, den Fehler zu reproduzieren.

Fixen von Bugs ist unter anderem so aufwändig, weil die tatsächliche Fehlerbehebung nur ein Schritt von vielen Schritten ist. Der Prozess an sich wird sich wahrscheinlich in Zukunft nicht wirklich ändern.

Ein übergeordnetes Problem wird aber nicht erwähnt…

Die verborgene Ursache und die eigentliche Herausforderung

Was passiert, wenn der Bug in einer alten Version auftritt? Das macht die Behebung noch mühsamer und zeitintensiver. Denn für Entwickler_innen bedeutet das: Die lokale Entwicklungsumgebung muss eventuell neu eingerichtet werden. Fehlt eine Abhängigkeit? Ist die korrekte Runtime vorhanden? Erst dann kann in die Tasten gehämmert werden. Ist der Bug behoben, beginnt die Prozedur von vorne. Das System muss für die aktuelle Version auf den korrekten Stand gebracht werden. Laut einer ActiveState-Umfrage benötigte der größte Anteil der Befragten (43,68 %) durchschnittlich 2-4 Stunden, um die Entwicklungsumgebung aufzusetzen. Das Einrichten einer Entwicklungsumgebung kann sogar bis zu 10 % der gesamten Entwicklungszeit ausmachen.

Was bedeutet das? Unternehmen sollten Wege finden, dieses Bottleneck – die Einrichtung der lokalen Entwicklungsumgebung – aus dem Arbeitsalltag zu schaffen.

Das Problem an der Wurzel packen und Bugs schneller beheben

Um das Problem an der Wurzel zu packen, benötigt es einen neuen Ansatz. Spricht man mit Entwickler_innen, so hat man oft das Gefühl, dass sich das Arbeiten in der lokalen Entwicklungsumgebung wie ein unebener Weg voller Schlaglöcher anfühlt, der sie immer wieder ins Stolpern bringt. Eine Umfrage von Gitlab bestätigt das. 61% der befragten Entwickler_innen berichten, dass sie zumindest einmal im Monat Zeit zur Problembehandlung mit ihrer lokalen Entwicklungsumgebung aufbringen – 31% sogar zumindest einmal pro Woche.

Es gibt eine Alternative. Remote Development Environments (RDEs):

• RDEs stellen den Entwickler_innen alle benötigten Versionen und Varianten der Software im Self-Service per Mausklick zur Verfügung.
• Keine umständliche Überprüfung von Abhängigkeiten.
• Kein zeitraubendes Einrichten der Entwicklungsumgebung bei einem Versionswechsel.

Was heißt das? Entwickler_innen konzentrieren sich mit RDEs tatsächlich auf die Problemlösung und müssen sich nicht mit Nebentätigkeiten herumschlagen. Ein schnelles Review für eine_n Kolleg_en_in ist genauso möglich, wie der Switch zu einer vorhergehenden Version. Ein Bug ist damit nicht viel mehr als eine einfache Gleichung, die mit wenigen Schritten gelöst werden kann – weil die dahinter liegenden Regeln und Prinzipien nicht immer neu erlernt werden müssen. Unternehmen profitieren, weil die neu gewonnene Zeit der Mitarbeiter_innen in die Weiterentwicklung der Software fließen kann.

Mehr dazu: Was sind Remote Development Environments?