Was zunächst eine berechtigte Frage zu sein scheint, basiert jedoch auf falschen Voraussetzungen:
- Die Anzahl der Programmzeilen seien gleichzusetzen mit Aufwand
- Einzelne Programmzeilen hätten einen Nutzen
- Alle Zeilen seien gleichwertig
Keine dieser Annahmen ist korrekt.
Warum hat eine so einfach erscheinende Anpassung dann zwei Tage gedauert?
- Weil das Ticket nur eine vage Beschreibung zur Reproduzierbarkeit enthält.
Es dauerte mehrere Stunden, um das Problem zuverlässig zu reproduzieren. Manche Entwickler_Innen hätten die Anfrage sofort an den Stakeholder zurückgegeben, mit der Meldung, dass mehr Informationen erforderlich sind. Stattdessen versuche ich so weit wie möglich mit den gelieferten Informationen zu kommen. Ich weiß, dass einige Entwickler_Innen Bugfixing nicht sonderlich mögen und kreativ werden, wenn es darum geht es zu umgehen. Vorzugeben es seien nicht genug Informationen zur Reproduktion vorhanden ist dabei natürlich eine großartige Möglichkeit: “Ich wollte ja helfen, aber ich konnte es nicht reproduzieren”. Ich hingegen versuche so viel wie möglich, bevor ich mit Rückfragen zum Stakeholder zurückgehe.
- Weil die Meldung sich auf eine Funktion bezieht, mit der ich noch nicht vertraut bin.
Ich kenne dieses Feature so gut wie gar nicht und habe es noch nie intensiv verwendet. Das bedeutet, dass ich mich zunächst in das Feature einarbeiten muss um zu verstehen, wie es mit dem Rest des Systems interagiert.
- Weil ich mir die Zeit zur Ursachenforschung nahm und nicht nur die Symptome bekämpft habe.
Wenn ein Stück Code eine Fehlermeldung erzeugt, kann man es einfach in ein try..catch Statement packen und den Fehler unterdrücken. Keine Meldung- kein Problem, richtig? Für mich ist es jedoch auf keinen Fall eine Lösung, das Problem nur unsichtbar zu machen. Eine Meldung einfach zu “verschlucken”, kann sehr leicht weitere Probleme nach sich ziehen und zu ungewünschten Seiteneffekten führen. Ich will es beim nächsten Mal nicht mit derartig entstandenen Seiteneffekten zu tun bekommen.
- Weil ich überprüft habe, ob das Problem nicht nur auf den gemeldeten, sondern auch auf anderen Wegen entsteht.
Die gemeldeten Schritte zur Reproduktion könnten nur eine mögliche Variante sein und die Ursache liegt ggf. tatsächlich viel tiefer. Die genaue Ursache zu finden und alle Möglichkeiten, wie diese zustande kommt, hilft jedoch die Randbedingungen zu verstehen. Ein solches Verständnis über den involvierten Code hilft abzuschätzen, ob noch andere Teile betroffen sind, die überprüft werden müssen.
- Weil ich mir die Zeit genommen habe zu prüfen, ob andere Teile des Codes auf eine ähnliche Weise betroffen sind.
Wenn ein Programmierfehler zu einem Bug führt, könnte er auch an anderen Stelle der Codebasis vorkommen. Genau jetzt ist es die Gelegenheit, dies zu überprüfen.
- Weil ich die eigentliche Ursache des Problems identifiziert habe und nun die effektivste Lösung suche, um es zu beheben und gleichzeitig das Risiko minimieren will, weitere unerwartete Seiteneffekte einzuführen.
Ich will nicht einfach nur den schnellstmöglichen Fix. Ich will einen Fix, der in der Zukunft möglichst wenig Verwirrung erzeugt und keine neuen Probleme verursacht.
- Weil ich alle Änderungen intensiv überprüft und getestet habe, um sicherzugehen, dass es für alle möglichen Szenarien das Problem behebt.
Ich will mich nicht auf jemanden anders verlassen, der prüft, ob das was ich gemacht habe auch richtig ist. Ich will nicht, dass demnächst ein neuer Bug entdeckt wird und ich erneut an dem selben Punkt ansetzen muss, während ich gedanklich schon bei einer anderen Baustelle bin. Ein Kontext-Wechsel ist mühselig und frustrierend. ich will unbedingt vermeiden, dass im Testing das selbe Problem erneut angeguckt werden muss.
Ich mag Bugfixing nicht. Zum einen fühlt es sich so an, als würde man mit seinem vorherigen Versagen konfrontiert werden. Zum anderen würde ich lieber an neuen Dingen arbeiten.
Was ist schlimmer als einen Bug fixen zu müssen?- Richtig, denselben Bug mehrfach fixen zu müssen. Ich nehme mir die Zeit, um sicherzugehen, dass ein Bug komplett gefixed ist, sodass er nicht immer und immer wieder geprüft, gefixed und getestet werden muss.
Original aus dem Englischen von Matt Lacey