Der Bug, der mir echtes Debugging beigebracht hat

Wer am Anfang seiner Entwicklerlaufbahn steht, kommt mit Tutorials im Gepäck. Hunderten davon. In jedem einzelnen tippt ein tiefenentspannter Mensch etwas Code, der auf Anhieb läuft, und sagt dann „und fertig!“ – wie ein Zauberer, den sein Kaninchen noch nie gebissen hat.

Ich war ein paar Schritte in meine Laufbahn hinein und ziemlich zuversichtlich, als ich meinem ersten echten Bug begegnete.

Und täglich grüßt die Datenschutzerklärung

Wir betreiben eine Web-App, in der sich Nutzerinnen und Nutzer registrieren und ein Häkchen setzen, dass sie die Datenschutzerklärung gelesen haben. (Haben sie nicht. Hat niemand. Nicht einmal die Juristinnen und Juristen, die sie geschrieben haben.)

Dann kam ein Bug-Report herein: Wer das Häkchen gesetzt hatte, landete beim nächsten Login wieder bei der Datenschutzerklärung. Häkchen weg. Als wäre nie etwas gewesen.

Stellen Sie sich vor, Sie unterschreiben am Empfang ein Formular, kommen am nächsten Tag wieder, und die Person am Empfang schiebt Ihnen lächelnd dasselbe Formular über den Tresen. Jeden Tag. Für immer. Genau das war unsere Login-Seite, mit der Ausstrahlung eines sehr höflichen Horrorfilms.

Als Neuzugang im Team dachte ich: „Das krieg ich hin.“ Liebe Leserschaft, ich kriegte es nicht hin.

Verdächtiger Nr. 1: Der Großbuchstabe

Innerhalb einer Stunde fand ich einen Bug. Bei der Registrierung speicherten wir die E-Mail-Adresse in Kleinbuchstaben. Beim Login suchten wir mit genau dem, was jemand eintippte. „Bharathi@“ und „bharathi@“ waren für unser System also zwei verschiedene Menschen – und einer von beiden hatte nie in irgendetwas eingewilligt.

Fall gelöst! Ich habe es behoben, deployt und mich zurückgelehnt wie Sherlock Holmes an seinem ersten Arbeitstag.

Der Bug war immer noch da.

Ich hatte offenbar den Falschen verhaftet. Schuldig war er schon – nur eben nicht in diesem Fall.

Lektion: Einen Bug zu finden ist nicht dasselbe, wie DEN Bug zu finden.

Die leere Schachtel

Also hörte ich auf zu raten und sah mir an, was der Server eigentlich zurückgibt, wenn eine angemeldete Person fragt: „Was weißt du über mich?“

Er gab {} zurück. Eine leere Schachtel.

Kein Fehler, kein Absturz. Nur ein zuversichtliches, gut gelauntes Nichts. So, als würden Sie bei Ihrer Bank nach dem Kontostand fragen und am Schalter ein geflüstertes „…“ hören, bevor aufgelegt wird.

Die Daten lagen die ganze Zeit in der Datenbank. Sie kamen nur nie heraus.

Lektion: Folgen Sie den Daten. Ihr Bauchgefühl hat die Codebasis nie gelesen.

Der Täter: Fünf Buchstaben

Unser Server hat einen Sicherheitsdienst. Er prüft, wer Sie sind, und zeigt Ihnen dann ausschließlich Ihre eigenen Daten. Dieser Dienst hatte außerdem eine VIP-Abkürzung: „Wenn das ein interner Systemaccount ist, einfach durchwinken.“

Irgendwann hatte jemand diese VIP-Prüfung erneuert. Statt die Liste auswendig zu kennen, musste der Dienst sie nun nachschlagen. Im Code schreibt man beim Nachschlagen await – also „warte auf die Antwort“.

An einer Stelle fehlte das await.

Der Sicherheitsdienst fragte also eine Kollegin: „Ist diese Person VIP?“ Die Kollegin sagte: „Moment, ich schaue nach …“ – und der Dienst, der den Rest gar nicht mehr abwartete, dachte sich „Klingt nach Ja!“ und winkte durch zur VIP-Tür.

Alle bekamen die VIP-Tür. Ausnahmslos alle.

Der Haken: Bei der VIP-Tür entfiel der Schritt, bei dem der Name auf einen Ausweis geschrieben wird. Alle liefen also ohne Ausweis hinein, und der Rest des Systems sah sie an und sagte: „Wer sind SIE denn? Sie bekommen gar nichts.“

Wir hatten versehentlich das sicherste System der Welt gebaut. Niemand konnte die Daten von irgendwem sehen – nicht einmal die eigenen.

Tage meines Lebens. Fünf Buchstaben. Kein Tutorial hatte mich je davor gewarnt.

Lektion: Kleine Änderungen haben Folgen. Man rückt einen Stuhl, und drei Zimmer weiter fällt eine Vase um.

Bonus-Bug, natürlich

Als ich schon einmal dort war, fand ich ein Flag für „verifiziertes Konto“, das bei allen auf „nein“ stand – auch bei verifizierten Konten. Die Prüfung dahinter schlug fehl, und statt sich zu beschweren, zuckte der Code mit den Schultern, schrieb „nein“ und machte weiter. Kein Fehler, kein Log. Nichts.

Ein Absturz schreit einen wenigstens an. Ein stiller Fehler ist die Kollegin, die den Drucker kaputt macht und sich leise davonstiehlt.

Wir lassen die Prüfung jetzt eine Warnung schreiben, wenn sie fehlschlägt, und haben eine kleine Selbstheilung ergänzt, die das Flag beim nächsten Login einer verifizierten Person korrigiert.

Lektion: Machen Sie Fehler laut. Ihr künftiges Ich verdient einen Hinweis.

Der Moment der Wahrheit

Wir haben deployt. Ich habe mich als Testnutzer angemeldet. Keine Datenschutzerklärung. Direkt aufs Dashboard, wie bei einer normalen Website von funktionierenden Erwachsenen.

Ich habe ein Geräusch gemacht. Über das Geräusch müssen wir nicht sprechen.

Was Tutorials nicht beibringen

1. Der erste Bug, den Sie finden, ist oft nur das Vorprogramm.
2. Hören Sie auf zu raten. Sehen Sie sich an, was tatsächlich passiert.
3. Wenn Sie etwas ändern, prüfen Sie alles, was sich auf die alte Fassung verlassen hat.
4. Stille Fehler lügen. Bringen Sie sie zum Reden.
5. Behoben ist es erst, wenn es im Produktivbetrieb behoben ist.

Am Anfang meiner Laufbahn dachte ich, gute Entwicklungsarbeit heiße, Code zu schreiben, der funktioniert. Dieser Bug hat mir beigebracht: Es geht vor allem darum, herauszufinden, warum Code nicht funktioniert – in aller Ruhe, während er einen anlächelt und einem eine leere Schachtel in die Hand drückt.

Manchmal läuft eine Woche Chaos auf ein einziges fehlendes Wort hinaus. Ich finde das entweder sehr beruhigend oder sehr beunruhigend – je nachdem, wie viel Kaffee ich hatte.

An alle, die unserer Datenschutzerklärung viermal hintereinander zugestimmt haben: danke. Sie haben sie offiziell öfter gelesen als sonst irgendwer. Und an den Bug: danke für die Lektion. Bitte komm nie wieder.