#096 Wie gehen wir mit Fehlern um, die schon immer da waren?
Fehler im alten Code, unbemerkt, weil Berichte funktionierten und sich der Business Case still veränderte: Reicht ein Fix oder braucht es Redesign? Sind eure Business Cases klar oder ist der Code längst zur schlechten Spezifikation geworden?
Wir reden über diesen Moment, in dem du ein altes Power-BI-Modell öffnest, eine kleine Änderung machen willst und plötzlich starrt dich eine Zahl an, die nie so hätte existieren dürfen. Jahre lang hat’s niemand gemerkt, weil die Berichte „funktionierten“. In der Zwischenzeit hat sich der Business Case leise verschoben. Also was tun mit Fehlern aus altem Code, weiterflicken oder neu denken? Und die eigentliche Gretchenfrage, sind eure Business Cases wirklich beschrieben oder ist der Code längst zur heimlichen Spezifikation geworden?
In dieser Episode nehmen wir euch mit in den Maschinenraum. Wir sprechen von Bugs, die nicht laut krachen, sondern nur ein bisschen schieben, bis sie ganze Entscheidungen in die falsche Richtung lenken.
Wir müssen uns dann fragen: Was ist hier eigentlich die Wahrheit, die Fachregel von heute oder die Logik von damals? Woher kommt der Fehler? Wen trifft er wirklich? Und was passiert mit den Berichten, die jeden Morgen pünktlich in Postfächern landen?
Manchmal reicht ein sauberer, kleiner Fix. Manchmal merkt man, der Code erzählt eine Geschichte, die niemand mehr unterschreiben würde. Dann hilft nur aufräumen und anpassen, so dass das Modell wieder zu dem passt, was das Business heute ist. Wir sprechen darüber, wie man währenddessen den Laden am Laufen hält, wie man Änderungen sichtbar macht, ohne Panik zu verbreiten, und warum ein paar gut erzählte Business-Regeln mehr bewirken als der schönste DAX-Zauber.
Wie sehen es Andreas und Marcus?
Marcus schaut zuerst auf die Governance-Seite. Für ihn ist klar, dass man Altfehler nicht einfach technisch beheben darf, ohne vorher die fachliche Grundlage zu prüfen. Sein Ansatz, erst definieren, wie es „heute“ richtig sein müsste und das sauber dokumentieren. Dann kann der Code angepasst werden. „Ein Bug ist oft nur das Symptom dafür, dass niemand mehr weiß, wie die Logik eigentlich gemeint war.“
Andreas kommt von der technischen Seite. Er sieht alte Fehler als Chance, die Architektur zu verbessern. Für ihn ist jeder Fund ein „Eintrittsticket“ in den Code, um aufzuräumen, zu modularisieren und Abhängigkeiten zu reduzieren. Sein Credo: „Wenn ich schon am offenen Herzen operiere, dann auch gleich den Bypass legen, der uns künftige Probleme erspart.“
Beide wollen, dass am Ende Fachlichkeit und Technik wieder übereinstimmen und dass der Code nicht länger als heimliche Dokumentation herhalten muss.
Unsere drei Learnings
- Transparenz vor Technik: Erst Klarheit über die fachlichen Regeln schaffen, dann bauen. Sonst bleibt jeder Fix ein Ratespiel.
- Altfehler sind Organisationsfehler: Ohne Zuständigkeiten, Tests und klare Definitionen bleiben Bugs unsichtbar, oft über Jahre.
- Struktur schlägt Aktionismus: Kleine, getestete Schritte mit klaren Guardrails verhindern das Fass-ohne-Boden-Gefühl.
Diskussionsfragen an euch
- Wo seid ihr zuletzt auf einen Altfehler gestoßen und warum konnte er so lange unentdeckt bleiben?
- Fix oder Redesign? Nach welchen Kriterien trefft ihr die Entscheidung in der Praxis?
- Ist bei euch der Business Case sauber beschrieben oder beschreibt der Code (noch) die Realität?
- Wie stellt ihr sicher, dass bestehende Berichte während der Korrektur weiter funktionieren?
- Welche Methoden/Tools helfen euch, Abhängigkeiten sichtbar zu machen und strukturiert aufzuräumen?
Wir freuen uns auf eure Erfahrungen, Tipps und Perspektiven rund um Modellpflege, Weiterentwicklung und nachhaltige BI-Lösungen!
Die Musik im Intro und Outro stammt aus dem Stück „There It Is“ von Kevin MacLeod und steht unter CC BY 3.0 Lizenz
https://freemusicarchive.org/music/Kevin_MacLeod/Funk_Sampler/There_It_Is