Feature by Fear: Wenn keiner mehr den Fehler anfassen will
Ich hatte gerade einen Fehler gefunden. Dachte ich jedenfalls.
Ein Teil des Systems lieferte einen Wert zurück, der aus technischer Sicht falsch war. Die Logik konnte so nicht stimmen – das war eindeutig. Also habe ich den Fall analysiert, reproduziert, eine saubere Lösung entwickelt und zum Review vorgelegt.
Die Reaktion: „Das ist kein Bug. Das muss so."
Wenn der Prozess gewinnt – und die Logik verliert
Was mich irritierte: Die Logik war objektiv falsch. Aber die Antwort war nicht fachlich, sondern prozessual. Man wusste, dass es „nicht korrekt" ist – aber der Prozess, wie er heute abläuft, erwartet genau dieses Verhalten. Und der Prozess sei wichtig. Unverhandelbar.
Das ist einer dieser Momente, in denen man als Entwickler schluckt. Du könntest das Problem lösen – aber du darfst es nicht.
Weil die Lösung den Prozess stören würde. Oder jemanden in der Fachabteilung verunsichert. Oder weil „es halt immer so war".
Ein Feature, das wie ein Bug aussieht – und umgekehrt
Solche Situationen sind keine Einzelfälle. Oft sind es Prozesse, die über Jahre gewachsen sind, sich an Systeme angepasst haben oder politische Rücksichtnahmen verkörpern. Sie sind nicht optimiert – sie sind einfach da. Und damit unantastbar.
In diesen Prozessen entstehen Verhalten, die für jeden Außenstehenden wie Bugs wirken. Aber intern gelten sie als „korrekt". Und wehe, du willst das ändern.
Was es noch schwieriger macht: Nicht selten sind selbst die Gründe für bestimmte Anforderungen im Dunkeln. Es heißt dann: „Das muss so – wegen regulatorischer Vorgaben." Fragt man nach, bleibt es vage: „Das war schon immer so." Oder: „Ich glaube, das hat mit irgendwelchen Richtlinien zu tun."
Diese Ungewissheit ist der wahre Gegner. Denn wie sollst du beraten, wenn niemand sicher sagen kann, ob das Ziel überhaupt gültig ist?
Beratung heißt auch: Unsicherheit sichtbar machen
Als beratender Entwickler musst du nicht alles wissen. Aber du musst den Mut haben, das Nicht-Wissen zu benennen.
Wenn du spürst, dass eine Anforderung auf wackligem Fundament steht, darfst du das nicht einfach ignorieren. Auch wenn es unbequem ist.
Du kannst aufzeigen, dokumentieren, Alternativen anbieten. Aber manchmal ist das Beste, was du tun kannst: Transparenz über die Unsicherheit schaffen.
Denn Prozesse ändern sich nicht durch besseren Code – sondern durch bessere Fragen.