Hug the Bug!

Von Bugs, Fehlern und Chancen: Wie Sie Bug-Tagebücher als Lerninstrument nutzen

Ann-Cathrin Klose

© Shutterstock / Sentavio

Jeder macht Fehler. Hier ein Bug, da ein fehlender Kommentar im Code, dort eine vergessene Aufgabe: Fehler gehören genau so sehr zum Arbeitsalltag, wie der morgendliche Kaffee. Und das ist eigentlich ganz gut so! Aus Fehlern kann man nämlich viel lernen. Wenn es also mal wieder so weit ist, sollte die Lektion im Zentrum der Aufmerksamkeit stehen, nicht das Problem. Dafür kann ein Bug-Tagebuch hilfreich sein.

Bugzilla, Jira und so weiter: Bugtracker gibt es viele am Markt. Fehler werden erfasst und übersichtlich dargestellt, sodass jeder Projekt-Beteiligte jederzeit weiß was zu tun ist. Die Verwendung eines solchen Systems gehört zum Standard in den meisten Projekten, häufig werden sogar Issues und nicht nur Bugs erfasst. Manche Probleme müssen schneller gelöst werden als andere; am Ende sollte der Bugtracker nie zu voll werden. Das würde ja die Stabilität des Produkts gefährden!

Zeit nehmen für den Bug

Was passiert aber mit Bugs, die bereits gelöst wurden? Die wenigsten Entwickler nehmen sich die Zeit, in Ruhe noch einmal durch bereits bearbeitete Bugs zu blättern und darüber nachzudenken, was diese über das System aussagen. Außerdem sind Bugs nicht unbedingt das liebste Gesprächsthema in vielen Teams: Niemand redet gern darüber, dass er etwas falsch gemacht hat. Genau das sollte aber viel häufiger stattfinden! Dadurch können nämlich viele Kollegen gleichzeitig etwas aus einem Bug lernen.

Um über Fehler zu sprechen, brauchen Mitarbeiter aber die richtige Einstellung. „Fail fast and often“ ist ein häufig zitierter Grundsatz der agilen Arbeitsweise – und doch scheint er dem Leistungsanspruch vieler Menschen zu widersprechen. Jeder möchte gut in seinem Job sein; Fehler (und dann auch noch viele davon) passen nicht ins Konzept. Auf den zweiten Blick macht die Idee der häufigen, schnellen Fehler aber durchaus Sinn. Immerhin passieren Fehler dann am häufigsten, wenn etwas Neues probiert wird. Die Aufforderung zum machen von Fehlern ist also auch eine Aufforderung dazu, kontinuierlich dazu zu lernen und sich somit stetig zu verbessern. Wer sich das bewusst macht, kann auch leichter darüber sprechen, was ihm gerade nicht so gut gelungen ist.

Was sagt mir der Bug?

Um so viel wie möglich aus einem Bug zu lernen, reicht es aber nicht, ihn zu lösen. Auch seine Herkunft und seine Bedeutung für das System müssen überdacht werden. Auf der einen Seite stehen dabei die üblichen kleinen Flüchtigkeitsfehler. Wer sich hier seine Muster bewusst macht, kann daraus natürlich etwas lernen. Auf der anderen Seite geht es meist aber gar nicht um so profane Dinge, sondern vielmehr um falsche Annahmen, die zu Bugs führen oder um ein völlig unerwartetes Nutzerverhalten, das Fehler verursacht, weil niemand an diese Möglichkeit gedacht hat.

Henrik Warne schlägt darum vor, ein Bug-Tagebuch zu führen, das die Lektionen festhält, die aus einem Fehler gezogen werden können. Darin wird natürlich nicht jeder winzige Fehler dokumentiert, sodass wirklich wichtige Erkenntnisse sofort ersichtlich sind. Darin unterscheidet sich sein Tagebuch deutlich von einem Bugtracker. Wer nach Jahren in Bugzilla etwas wiederfinden möchte, muss es zwischen unzähligen Kleinigkeiten heraussuchen. Im Bug-Tagebuch finden sich hingegen nur die Problematiken, die tatsächlich mehr als drei Minuten Aufwand erfordert haben und eine weitergehende Relevanz besitzen.

In Ruhe über das Problem nachdenken

Schon zu Schulzeiten war es bei der Vorbereitung auf Prüfungen ein gutes Zeichen, wenn der Stoff in eigenen Worten wiedergegeben werden konnte – so ähnlich ist es auch mit dem Bearbeiten von Bugs, wie Warne sagt. Wer nach der Lösung eines Problems noch einmal zusammenfasst, was er getan und daraus gelernt hat, festigt sein Wissen und bekommt einen ganz neuen Blickwinkel auf das Problem. Neben der richtigen Einstellung ist aber auch ein wenig Disziplin notwendig, um ein solches Tagebuch zu führen. Warne ist bestimmt nicht der einzige Entwickler, der nach dem Debuggen lieber etwas anderes machen würde, als noch einmal darüber zu schreiben. Auf lange Sicht lohnt es sich aber wohl doch, ein paar Extra-Minuten in die kleineren und größeren Bugs eines Produkts zu investieren.

Warne nutzt für sein Bug-Tagebuch einfaches Text-Dokument, in das er seine Bug-Berichte nach einem festen Schema einfügt. Neben dem Datum, der aufgetretenen Problematik und dem Grund für den Fehler dokumentiert er auch, wie das Problem gelöst wurde, wo sich der gefixte Code befindet, wer für den Bug verantwortlich war, wie lange die Lösung gedauert hat und die Lektion, die er aus diesem Problem gelernt hat. Zusammen ergibt sich so eine übersichtliche Auflistung der Charakteristika eines Bugs.

Lessons learned

Die Lektion, so erklärt Warne weiter, ist dabei natürlich der wichtigste Teil des Tagebuchs. Seine Lektionen können sich grundlegend auf drei verschiedene Bereiche beziehen: Entweder geht es darum, dass das Problem gar nicht erst hätte auftreten sollen – dann liegt ein vermeidbarer Fehler im Code vor. Oder hätte der Bug zumindest beim Testen gefunden werden müssen, tauchte aber erst in der realen Anwendung auf? Dann müssen die Tests verbessert werden. Auch das Debugging kann oft verbessert werden, um zukünftig Zeit zu sparen. Auch dabei, die eigene Arbeitsweise zu verbessern, kann ein Blick ins Bugtagebuch helfen.

Und wenn die Bugs mal wieder zu sehr nerven, kann es durchaus helfen, sich einmal vor Augen zu führen, dass es nicht nur bei der Erstellung neuen Codes um eine spannende Herausforderungen und Rätsel geht. Natürlich macht es Spaß, ganz neue Funktionen zu realisieren und ein völlig neuartiges Produkt zu entwickeln. Was aber macht den Reiz daran aus? Schlussendlich sind die meisten Entwickler fasziniert davon, Probleme zu lösen und Hürden zu überwinden. Und das ist ja gar nicht so anders, wenn es um das Abarbeiten von Bugs geht. Auch hier gibt es Muster zu entdecken und Hinweise zu interpretieren, es muss unkonventionell gedacht und ein kleines Detail erkannt werden. Das ist nicht das gleiche wie das Schreiben eines ganz neuen Codes – aber eigentlich auch gar nicht so verschieden. Und die Befriedigung, am Ende ein gutes Produkt realisiert zu haben, sollte sich doch sowohl beim Debuggen als auch beim Schreiben von neuem Code einstellen.

Aufmacherbild: Program code bug technology development programming coding via Shutterstock / Urheberrecht: Sentavio

Geschrieben von
Ann-Cathrin Klose
Ann-Cathrin Klose
Ann-Cathrin Klose hat allgemeine Sprachwissenschaft, Geschichte und Philosophie an der Johannes Gutenberg-Universität Mainz studiert. Bereits seit Februar 2015 arbeitete sie als redaktionelle Assistentin bei Software & Support Media und ist seit Oktober 2017 Redakteurin. Zuvor war sie als freie Autorin tätig, ihre ersten redaktionellen Erfahrungen hat sie bei einer Tageszeitung gesammelt.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: