Computer tun ja bekanntlich nicht immer das, was von ihnen erwartet wird. Sogar, oder insbesondere, als Softwareentwickler ist man oft vom Verhalten der eigenen Systeme überrascht. Wie aber reagiert man am besten, wenn die gerade frisch gestartete Version des Programms keinen Mucks von sich zu geben scheint oder der neue HTTP-Request nur zu einer leeren Antwort führt?

Häufig springt sofort der Verstand an und versucht, sich zu überlegen, was wohl falsch gelaufen sein könnte. Haben die Unittests nicht alle Fälle abgedeckt und einen Bug übersehen? Wurde vielleicht bloß ein neuer Konfigurationsparameter vergessen? Ist die URL des Test-Requests wirklich richtig geschrieben? Ist überhaupt die richtige Version gebaut, installiert und gestartet worden? Die Auswahl an möglichen Fehlern ist unendlich groß! Daher möchte ich hier mal eines meiner liebsten Schlagworte empfehlen:

„Denken bringt nix!“ (Danke, @Badesalz!)

Denn genau so wie es sinnlos ist, über den Inhalt eines noch ungeöffneten Briefumschlags zu sinnieren, ist es auch unnütz, über die Verhaltensauffälligkeiten eines Computers nachzudenken, solange – und jetzt kommt die notwendige Präzisierung der Regel – man noch nicht über alle vorhandenen Informationen verfügt. Nachsehen statt vermuten, analysieren statt spekulieren! Wie sieht die Antwort denn ganz genau aus, auch ihre Header? Ist die gerade getestete Version der Software tatsächlich die beabsichtigte? Hat der Service etwas Auffälliges ins Logfile geschrieben, als er den Request bekam? Oder vielleicht schon beim Start? Oder hat er etwas Spezielles nicht geschrieben, was aber erwartet wurde? Bis wohin kann man dadurch den Ablauf im Quelltext nachvollziehen? Könnte das Problem mit einem höheren Loglevel besser eingegrenzt werden? Welche Werte stehen denn nun in der Konfiguration? Woher kommt sie? Wie ist ggf. der Zustand von betroffenen Datenbanken? Funktionieren andere, ältere oder einfachere Dinge?
Sollte das Logging für diesen Fall erweitert werden? Muss dann vielleicht doch der Debugger angeworfen werden? Idealerweise baut man die Software auch bereits so, dass die relevanten Informationen dann einfach auffindbar sind.

Natürlich gibt es bei all diesen Fragen eine Menge zu denken – ohne geht es nicht. Aber man sollte sich dabei auf die richtigen Gedanken fokussieren, d.h. an erster Stelle auf die Informationsgewinnung. Nachdenken ohne ausreichende Datenbasis ist Zeitverschwendung und kann auch leicht in die Irre führen. Die wichtigsten Fragen sind daher die, welche mit wenig Aufwand objektiv beantwortet werden können, und die dadurch helfen, bestimmte Fehlerquellen auszuschließen oder auf andere hinzuweisen.

Die überflüssigsten Gedanken sind hierbei übrigens solche, die sich mit Überraschung oder Ärger befassen. Dass Software bzw. neue Funktionen beim ersten Start nicht gleich korrekt funktionieren ist die Regel, nicht die Ausnahme. Der gute Software-Handwerker schaut dann ganz genau hin, an welcher Stelle es noch wackelt, und schleift eben noch mal nach.

Robert Linden, Softwarearchitekt und Softwareentwickler